Sözleşme Testleri (Contract Testing): Tüketici Odaklı PACT (Pact.io) ve Takımlar Arası Sessiz API Kırılmaları

Staff/Principal (L6+)

⚡ÖZET VE TEKNİK CEVAP

Bağımsız mikroservis organizasyonlarında en sinsi canlı kesintileri entegrasyon sınırlarında yaşanır: Backend Takımı bir API yanıtındaki user_id alanının adını userId yapar veya durum kodunu 200 yerine 204 döner. Backend birim testleri %100 geçer ve kod canlıya başarıyla dağıtılır. 10 dakika sonra ise tüm Mobil iOS/Android uygulamaları JSON çözümleme hatası vererek açılır açılmaz çöker. Geleneksel çözümler yetersizdir: Uçtan uca test ortamları yavaş, kararsız ve aşırı pahalıdır. Tüketici Odaklı Sözleşme Testleri (Consumer-Driven Contract Testing - Pact.io) bu kırılmaları kod seviyesinde yok eder:

Tüketici Sözleşmeyi Yazar: Tüketici (Mobil/Frontend ekibi) beklediği istek ve yanıt şemasını kodla tanımlar ve silinemez bir Pact Sözleşmesi üretir.

Sağlayıcı CI'da Doğrular: Backend ekibi bir PR açtığında, CI hattı mobil ekibin sözleşmesini backend üzerinde otomatik çalıştırır.

Can-I-Deploy Kapısı: Canlıdaki aktif mobil uygulama sürümü eski şemaya bağımlıysa, can-i-deploy aracı backend'in canlıya çıkışını anında kilitler.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Tüketici Odaklı Sözleşme Testi Pact Broker yaşam döngüsüyle çalışır:

Tüketici Testi: Mobil istemci Pact SDK'sı ile bir test yazar (GET /api/v1/user/10 çağrısının {\"user_id\": string} döneceğini şart koşar). Pact otomatik bir mobil-backend.json sözleşmesi üretir.

Pact Broker'a Yayınlama: CI sözleşmeyi merkezi Pact Broker kütüphanesine version: v4.2.0-canli etiketiyle yükler.

Sağlayıcı CI Doğrulaması: Backend CI hattı Pact Broker'daki tüm aktif sözleşmeleri çeker ve backend koduna karşı çalıştırır.

can-i-deploy Dağıtım Kapısı: Dağıtımdan önce pact-broker can-i-deploy komutu çalıştırılır; sözleşme kırılmışsa canlıya çıkış otomatik olarak engellenir.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Mikroservisler arası REST/gRPC API entegrasyonları, mobil-backend sözleşme yönetişimi, çok takımlı bağımsız dağıtımlar ve dağıtık sistem sürüm koordinasyonu.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
Apple App Store onay süreçleri yüzünden anında güncellenemeyen mobil uygulamaları düşünmeden backend JSON alanını değiştirmek ve milyonlarca telefonda uygulamanın çökmesi
✓
gerçek istemci ihtiyaçlarını yansıtmayan sahte verilere güvenmek

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

✓
Frontend geliştiricilerin API'nin bozulduğunu ancak backend canlıya çıktıktan sonra fark etmesi
✓
mobil uygulamaların canlıda KeyNotFoundException hatasıyla çökmesi
✓
takımların 50 servisi aynı anda ayağa kaldırmaya çalışan hantal test ortamlarında boğulması

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
Tüm servisler arası API'lerde Pact.io ile Tüketici Odaklı Sözleşme Testini zorunlu kılın
✓
CI/CD hatlarına can-i-deploy kontrolünü ekleyin
✓
alan değişikliklerinde Genişlet ve Daralt (Expand-and-Contract) geçiş modelini uygulayın

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Tüketici Odaklı Sözleşme Testleri takımlar arası API kırılmalarını tamamen yok eder ve hantal test ortamlarının yerini alır; ancak hem istemci hem sunucu takımlarının Pact araçlarını CI hatlarına entegre etmesini gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir bankanın 4 milyon aktif iOS kullanıcısı vardı. Backend takımı transfer servisini refactor ederken accountNumber alanını account_number olarak değiştirdi. Tüm backend testleri geçti. Canlıya çıkıldığında mobil uygulama transfer ekranında 4 milyon kullanıcının telefonunda anında çöktü. Apple App Store'dan acil mobil yama onayı almak 24 saat sürdüğü için kesinti tam bir gün devam etti ve büyük itibar kaybı yaşandı. Şirket Pact.io'ya geçti: Mobil ekip sözleşmelerini merkezi Pact Broker'a yükledi. Sonraki alan değişikliği denemesinde backend CI sistemi anında kırmızı yandı: Pact Doğrulaması Başarısız: iOS Uygulaması 'accountNumber' alanını bekliyor. Backend ekibi iki alanı aynı anda destekleyerek canlıya sıfır çökmeyle çıktı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

Mikroservis mimarilerinde 'Tüketici Odaklı Sözleşme Testi' (Consumer-Driven Contract Testing) nedir?

Bir API'yi tüketen tarafın (ör. Mobil Uygulama veya Frontend) ihtiyaç duyduğu istek ve yanıt şemasını kodla sözleşmeye bağladığı; API'yi sunan tarafın (Backend) ise canlıya çıkmadan önce CI boru hattında bu sözleşmeyi otomatik olarak doğruladığı test metodolojisidir.

Pact `can-i-deploy` komut satırı aracı CI/CD dağıtım hatlarında ne işe yarar?

Pact Broker kütüphanesini sorgulayarak canlıya alınacak backend sürümünün, şu an canlıda aktif olarak çalışan tüm mobil ve frontend istemci sürümleriyle %100 uyumlu olduğunu matematiksel olarak doğrular; uyumsuzluk varsa dağıtımı anında durdurur.

Sözleşme Testleri (Contract Testing): Tüketici Odaklı PACT (Pact.io) ve Takımlar Arası Sessiz API Kırılmaları — Sıkça Sorulan Sorular

Sözleşme testleri (Contract Testing) neden devasa uçtan uca (E2E) test ortamlarından çok daha üstündür?

Çünkü uçtan uca test ortamları yavaş, kararsız, bakımı çok pahalı ve sürekli çöken ortamlardır; oysa sözleşme testleri CI boru hattında milisaniyeler içinde çalışan hızlı ve kararlı birim testleridir.

API alanlarını güvenle yayından kaldırmak (deprecate) için kullanılan 'Genişlet ve Daralt' (Expand-and-Contract) modeli nedir?

Önce API'yi genişleterek hem eski hem yeni alan adını aynı anda destekleyin; tüm istemcilerin yeni alana geçtiğinden emin olun; aylar sonra eski alanı güvenle silerek API'yi daraltın.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸
Mobil uygulamalar anında güncellenemediği için backend alan değişiklikleri telefonları çökertir.
▸
Tüketici Odaklı Sözleşme Testi (Pact.io) beklenen şemanın istemci tarafından yazılmasını sağlar.
▸
Backend CI boru hatları kodu tüm aktif istemci sözleşmelerine karşı otomatik doğrular.
▸
Canlıya kod çıkmadan önce mutlaka can-i-deploy kontrolünü zorunlu kılın.

Yaygın Yanılgılar

✗
Yanılgı: %100 backend test kapsamı API kırılmalarını önler (Gerçek: Backend birim testleri sadece backend'in kendi varsayımlarını test eder; mobilin ne beklediğini bilemez).
✗
Yanılgı: OpenAPI / Swagger şemaları sözleşme testi için yeterlidir (Gerçek: Statik OpenAPI şemaları sadece dokümandır; kodun çalıştığını doğrulayan canlı testler değildir).

Karar Kılavuzu & Önceliklendirme

Takımlar arası sessiz API kırılmalarını yok etmek ve mobil uygulama kararlılığını korumak için Pact.io ile Tüketici Odaklı Sözleşme Testlerini kurun ve can-i-deploy kapısını zorunlu kılın.

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL_DOCUMENTATION]Pact Foundation: Consumer-Driven Contract Testing Principles & Can-I-Deploy Patterns— Pact.io Open Source Documentation

Bu sayfadaki teknik terimler

Application Programming Interface Continuous Integration Server