Integration Testing

.NET 10 | WebApplicationFactory و تست Contract HTTP

Integration Test چند جزء واقعی را در کنار هم بررسی می‌کند و برای Pipeline، Routing، Serialization، Authentication و Data Access ارزش ویژه دارد. سرعت آن کمتر از Unit Test است اما خطاهای اتصال اجزا را آشکار می‌کند.

این فصل با تمرکز بر قراردادهای قابل اتکا، مرزبندی مسئولیت‌ها و رفتار قابل پیش‌بینی در محیط واقعی تنظیم شده است. مثال‌ها بر پایه ASP.NET Core و .NET 10 نوشته شده‌اند.

1. چارچوب موضوع و مفاهیم اصلی

Integration Test چند جزء واقعی را در کنار هم بررسی می‌کند و برای Pipeline، Routing، Serialization، Authentication و Data Access ارزش ویژه دارد. سرعت آن کمتر از Unit Test است اما خطاهای اتصال اجزا را آشکار می‌کند.

واژگان و قراردادهای این بخش باید در سراسر پروژه یکدست بمانند؛ تفاوت میان لایه HTTP، منطق برنامه و زیرساخت زمانی روشن می‌ماند که مسئولیت هر جزء به‌صورت صریح تعریف شود.

2. ساختار پیشنهادی در پروژه

Application با WebApplicationFactory بالا می‌آید و Dependencyهای Production در محیط Test جایگزین می‌شوند. Database هر تست یا مجموعه تست باید وضعیت قابل پیش‌بینی داشته باشد.

public sealed class ProductsApiTests : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient _client;

    public ProductsApiTests(WebApplicationFactory<Program> factory)
    {
        _client = factory.CreateClient();
    }

    [Fact]
    public async Task Get_products_returns_ok()
    {
        var response = await _client.GetAsync("/api/products");
        Assert.Equal(HttpStatusCode.OK, response.StatusCode);
    }
}

3. سناریوی اجرایی

برای Endpoint محافظت‌شده، Token معتبر و نامعتبر تست می‌شود. همچنین Validation، Status Code و JSON واقعی پاسخ بررسی می‌شوند تا Contract در سطح شبکه پوشش داده شود.

در این سناریو، قرارداد ورودی و خروجی، مسیر شکست و رفتار قابل مشاهده سرویس باید پیش از جزئیات پیاده‌سازی مشخص شود. این رویکرد باعث می‌شود تغییرات بعدی بدون وابستگی پنهان و با امکان تست دقیق انجام شوند.

var response = await client.PostAsJsonAsync("/api/products", new
{
    name = "",
    price = -1
});

Assert.Equal(HttpStatusCode.BadRequest, response.StatusCode);

4. اصول طراحی و نگهداری

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

• Test Database از Production کاملاً جدا باشد.
• State بین تست‌ها Reset شود.
• Integration Test Contractهای مهم را پوشش دهد، نه همه ترکیب‌های کوچک.
• External APIها با Test Double در Boundary مناسب کنترل شوند.

5. خطاهای رایج و کنترل آن‌ها

بخش مهمی از کیفیت یک API در نحوه جلوگیری از خطاهای تکرارشونده مشخص می‌شود. موارد زیر باید در بازبینی کد و تست‌های قبل از انتشار کنترل شوند.

• استفاده از دیتابیس مشترک توسعه‌دهندگان.
• تست وابسته به زمان یا داده باقی‌مانده از تست قبلی.
• نادیده گرفتن Authentication و Middlewareها.
• کند کردن Suite با تکرار سناریوهای Unit.

6. چک‌لیست نهایی فصل

• API در Test Host بالا می‌آید.
• Database تست ایزوله است.
• Status Code و Response Body بررسی می‌شوند.
• سناریوهای Security و Validation اصلی پوشش دارند.

7. جمع‌بندی

مفاهیم این فصل زمانی کامل محسوب می‌شوند که هم مسیر موفق و هم مسیر خطا قابل پیش‌بینی، قابل تست و قابل مشاهده باشند. طراحی نهایی باید با Contract API، امنیت و نیازهای نگهداری پروژه هماهنگ بماند.