.NET'te consumer-driven contract testing: API kırılmalarını deploy öncesi yakalayın
Mikroservis mimarisinde bir servisin kendi testleri geçse bile başka bir servisin beklediği JSON alanını değiştirmesi production'da sessiz hatalara yol açabiliyor. Bu rehber, .NET 10 ve PactNet 5.0.1 ile consumer sözleşmeleri üretmeyi, provider doğrulamasını, Pact Broker'ı ve OpenAPI diff kontrolünü CI/CD kapılarına bağlamayı adım adım anlatıyor.
Kilit noktalar
- PactNet 5.0.1 ve .NET 10 LTS ile Pact specification v4 kullanan consumer sözleşmeleri üretiliyor
- Provider verification, consumer'ın gerçek `HttpClient` ve `System.Text.Json` ayarlarını test eder; elle yazılmış istekler yeterli değil
- Provider state'ler ön koşulları tanımlar ("product 101 exists"); her interaction bağımsız çalışmalıdır
- Pact ve OpenAPI birbirini tamamlar: `oasdiff` hiçbir Pact tarafından egzersiz edilmeyen endpoint kaybını, Pact ise spec değişmeden oluşan runtime serialization farkını yakalar
- CI'da PactNet'in native bileşenleri için Alpine değil, glibc tabanlı Ubuntu x64 runner kullanın
- Broker ve PostgreSQL yerelde Compose ile ayağa kaldırılabilir; CI'da image digest'lerini pinleyin ve yerel kimlik bilgilerini değiştirin
Mikroservislerde bağımsız deploy, sürüm uyumluluğu problemini beraberinde getiriyor: production'da her servisin son commit'i değil, farklı release kombinasyonları çalışıyor. Yazar, Product API'nin `price` alanını `unitPrice` olarak değiştirmesi örneğiyle bunu somutlaştırıyor; iki taraf da kendi testlerini geçse bile Order Service ya exception alıyor ya da sıfır fiyatla sessizce yanlış sipariş oluşturuyor.
Çözüm, tüketicinin beklentisini çalıştırılabilir hale getirmek. Order ve Shipping servislerinin PactNet ile kendi sözleşmelerini üretmesi, Pact Broker üzerinden yayınlanması ve provider doğrulamasında gerçek endpoint'e karşı kontrol edilmesi öneriliyor. Yazı ayrıca provider durumları, matching rule'lar, `oasdiff` ile OpenAPI karşılaştırması ve PactNet'in native bileşenleri nedeniyle Alpine yerine glibc tabanlı runner kullanılması gibi pratik uyarıları da kapsıyor.
Gerçek dünyada kullanımı
- Sipariş servisi ile ürün kataloğu API'si arasındaki fiyat/para birimi sözleşmesini, provider ekibi deploy etmeden önce doğrulamak
- Birden fazla tüketicisi olan bir ASP.NET Core API'de yalnızca etkilenen ilişkiyi kırmızıya düşürmek, tüm API'yi tek sözleşme gibi ele almamak
- Kargo/faturalama gibi yalnızca birkaç alana ihtiyaç duyan tüketicilerin gereksiz alanları sabitlemesini engellemek
- CI pipeline'ında Pact Broker'daki doğrulama sonuçlarına bakarak hangi servis sürümünün hangi ortama çıkabileceğine karar vermek
Neden önemli
API uyumluluğunu deploy sonrası staging'de değil, saniyeler içinde çalışan testlerle merge öncesinde görürsünüz; böylece koordineli release zorunluluğu olmadan servisleri bağımsız çıkarmaya devam edebilirsiniz.