Class Fixture 🏠 :
یک کانتینر برای هر کلاس تست:

زمانی استفاده کنید که تست‌ها وضعیت سراسری را تغییر می‌دهند یا دیباگ کردن تعاملات تست دشوار می‌شود.

public class AddItemToCartTests : IClassFixture<DevHabitWebAppFactory>
{
    // ...
}

Collection Fixture 🏢 :
یک کانتینر مشترک بین چندین کلاس تست:

زمانی استفاده کنید که تست‌های شما وضعیت اشتراکی را تغییر نمی‌دهند یا می‌توانید به طور قابل اعتماد بین تست‌ها پاک‌سازی انجام دهید.

[CollectionDefinition(nameof(IntegrationTestCollection))]
public sealed class IntegrationTestCollection : ICollectionFixture<DevHabitWebAppFactory> {}

// سپس آن را به کلاس‌های تست خود اعمال کنید:
[Collection(nameof(IntegrationTestCollection))]
public class AddItemToCartTests : IntegrationTestFixture
{
    // ...
}

چه زمانی از کدام استفاده کنیم:🤔

🔹️Class fixtures
وقتی به ایزوله‌سازی کامل بین کلاس‌های تست نیاز دارید (کندتر اما امن‌تر).

🔹️Collection fixtures
وقتی کلاس‌های تست با یکدیگر تداخل ندارند (سریع‌تر اما نیازمند نظم).

نوشتن تست‌های یکپارچه‌سازی قابل نگهداری ✍️
با پیکربندی صحیح زیرساخت، تست‌های واقعی شما باید روی منطق بیزینس تمرکز کنند:

[Fact]
public async Task Should_ReturnFailure_WhenNotEnoughQuantity()
{
    //Arrange
    Guid customerId = await Sender.CreateCustomerAsync(Guid.NewGuid());
    // ...

    //Act
    Result result = await Sender.Send(command);

    //Assert
    result.Error.Should().Be(TicketTypeErrors.NotEnoughQuantity(Quantity));
}

توجه کنید که چگونه تست‌ها به جای دغدغه‌های زیرساختی، روی قوانین بیزینس تمرکز دارند. شما PostgreSQL یا Redis را mock نمی‌کنید، شما رفتار واقعی را تست می‌کنید.

نتیجه‌گیری 👍
تست کانتینر‌ها تست یکپارچه‌سازی را با دادن اطمینانی که از تست در برابر وابستگی‌های واقعی حاصل می‌شود، متحول می‌کند.

ساده شروع کنید: یک تست یکپارچه‌سازی را که در حال حاضر از mockها یا دیتابیس‌های درون-حافظه‌ای استفاده می‌کند، انتخاب کرده و آن را برای استفاده از Testcontainers تبدیل کنید. بلافاصله تفاوت در اطمینان را هنگامی که آن تست پاس می‌شود، متوجه خواهید شد.