Birim testleri iş kurallarını hızlı doğrular; fakat routing, model binding, kimlik doğrulama ve gerçek SQL davranışını birlikte sınamaz. Integration test, uygulamayı gerçek başlangıç hattıyla ayağa kaldırıp HTTP seviyesinden kullanır. Böylece migration hataları, yanlış DI kayıtları ve yalnızca belirli veritabanlarında ortaya çıkan sorgu sorunları yayın öncesinde yakalanır.

İzolasyon neden önemlidir?

Testlerin geliştiricinin bilgisayarındaki ortak veritabanına bağlanması sonuçları sıraya ve mevcut verilere bağımlı hâle getirir. Her test çalışması için geçici bir veritabanı oluşturmak daha güvenlidir. Container kullanıldığında CI sunucusu ve yerel makine aynı SQL sürümünü çalıştırır. Test bittiğinde container kaldırılır; geride elle temizlenecek veri kalmaz.

API uçtan uca testi

Aşağıdaki test gerçek HTTP isteği gönderir ve yalnızca durum kodunu değil dönen sözleşmeyi de doğrular. Factory yapılandırmasında uygulamanın connection string'i geçici veritabanıyla değiştirilir ve migration uygulanır.

public sealed class OrdersApiTests : IClassFixture<BlogApiFactory>
{
    private readonly HttpClient _client;

    public OrdersApiTests(BlogApiFactory factory)
        => _client = factory.CreateClient();

    [Fact]
    public async Task Create_order_returns_created_resource()
    {
        var response = await _client.PostAsJsonAsync(
            "/api/orders", new { customerId = 42, total = 125 });

        response.StatusCode.Should().Be(HttpStatusCode.Created);
        var order = await response.Content.ReadFromJsonAsync<OrderResponse>();
        order!.CustomerId.Should().Be(42);
    }
}

Test yalnızca controller metodunu çağırmaz; middleware, JSON serileştirme, doğrulama, service ve database katmanları birlikte çalışır. Başarılı test gerçek sistemin tamamını kanıtlamaz, ancak katmanlar arasındaki sözleşme hatalarını güçlü biçimde yakalar.

Sağlam bir test paketi için

1. Test veritabanına uygulamanın kullandığı migration'ları otomatik uygulayın.
2. Her test için transaction geri alma veya benzersiz veri anahtarıyla izolasyon sağlayın.
3. Başarılı isteklerin yanında 400, 401, 403, 404 ve çakışma senaryolarını test edin.
4. Saat ve dış HTTP servisleri gibi değişken bağımlılıkları kontrollü test uygulamalarıyla değiştirin.
5. CI sürecinde container loglarını hata durumunda artefact olarak saklayın.

Sık yapılan hatalar

• InMemory provider kullanıp gerçek SQL Server sorgu ve kısıt davranışını test ettiğini varsaymak.
• Testlerin aynı kayıtları paylaşmasına izin vererek paralel çalışmada rastgele hatalar üretmek.
• Her ayrıntıyı integration test ile sınayıp yavaş ve bakımı zor bir test piramidi kurmak.

Sonuç

En verimli strateji, çok sayıda hızlı birim testi ile kritik akışları kapsayan daha az sayıda integration testini birleştirir. Kullanıcı kaydı, yetkilendirme, ödeme ve veri bütünlüğü gibi sınırlar gerçek altyapıyla test edilmeye değerdir. Geçici veritabanı yaklaşımı bu testleri tekrarlanabilir ve CI ortamına taşınabilir hâle getirir.