Skip to main content

> tüketici_odaklı_sözleşme_testleri_ve_pact

Tüketici Odaklı Sözleşme Testleri ve Pact

Yüksek verimli canlı mimarilerde Tüketici Odaklı Sözleşme Testleri ve Pact yapısını nasıl doğru kurar ve yönetirsiniz?

Stack: SOFTWARE ARCHITECTURE STACK →Senior (L5)pattern

ÖZET VE TEKNİK CEVAP

Tüketici Odaklı Sözleşme (CDC) testleri, API tüketicilerinin ihtiyaç duydukları kesin alan ve uç noktaları çalıştırılabilir sözleşmeler (Pact) olarak tanımlamasını sağlar; sağlayıcılar bu sözleşmeleri CI sürecinde doğrulayarak canlıda kırıcı değişiklikleri önler.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Mikroservis ekosistemlerinde servisler arası uyumluluğu ortak staging ortamlarında uçtan uca test etmek yavaş, kırılgan ve yalancı hatalarla doludur. Tüketici Odaklı Sözleşme testleri bu dinamiği tersine çevirir: tüketiciler ihtiyaç duydukları beklentileri Pact Broker'a sözleşme olarak yükler; sağlayıcı CI sürecinde bu sözleşmeleri doğrular.

2. Doğru Kullanım Senaryosu

Tüketici Odaklı Sözleşme testi, API tüketici beklentilerinin resmi sözleşmelere dönüştürüldüğü ve API sağlayıcıları tarafından izole birim test süreçlerinde bağımsız olarak doğrulandığı bir test metodolojisidir.

3. Prodüksiyon Arıza Modları

Staging ortamında aynı anda 50 mikroservisin ayağa kalkmasını gerektiren hantal uçtan uca testler yazmak. API sağlayıcılarının gerçek tüketicilerin o alanları nasıl kullandığını doğrulamadan kafalarına göre OpenAPI şeması yayınlaması. Acil hotfix sırasında `can-i-deploy` kontrolünü baypas edip canlıda kırıcı şema değişiklikleri yayına almak.

4. Teşhis ve Telemetri Sinyalleri

sağlayıcıdaki alan adı değişikliği canlı ortamda alt tüketiciyi çökertir, sürekli çöken uçtan uca entegrasyon test ortamları, koordinasyonsuz API dağıtımı kaynaklı kesintiler

5. Önleme ve Mimari Bariyerler

`pact-broker can-i-deploy` kontrolünü doğrudan CI/CD boru hattınızın canlıya çıkış kapısına entegre edin. Sağlayıcı sözleşme testlerini çalıştırmadan önce veritabanı durumunu temiz kurmak için Provider State mekanizmasını kullanın. Tüketici sözleşmelerini yalnızca tüketicinin gerçekten okuduğu alanlarla sınırlayın; kullanılmayan alanları sözleşmeye eklemeyin.

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

CDC testleri kırılgan staging entegrasyon ortamlarına olan ihtiyacı ortadan kaldırırken, yeni bir sağlayıcı sürümünün canlıdaki tüketicileri bozmayacağına dair kesin mühendislik güvencesi sunar.

Vaka İncelemesi (TinyCTO Örneği)

CDC yaşam döngüsü dört otomatik aşamadan oluşur: 1. **Tüketici Testi:** Tüketici servis Pact tarafından üretilen sahte HTTP sunucusuna karşı birim testler yazar. Testler geçtiğinde Pact kesin istek ve yanıt şemasını içeren bir JSON sözleşmesi (`pact.json`) üretir. 2. **Pact Broker'a Yükleme:** Tüketicinin CI boru hattı sözleşmeyi merkezi Pact Broker'a git commit SHA'sı ve ortam etiketiyle yükler. 3. **Sağlayıcı Doğrulaması:** Sağlayıcı servis Pact Broker'daki tüm aktif sözleşmeleri çeker ve sahte sağlayıcı durumlarıyla yerel controller katmanında çalıştırır. 4. **`can-i-deploy` Onay Kapısı:** Canlıya çıkmadan önce servis Pact Broker'a sorar: `pact-broker can-i-deploy --pacticipant OrderService --version $GIT_SHA --to-environment production`. Tüm matris kombinasyonları başarılıysa 0 kodu döner.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Mikroservislerde Tüketici Odaklı Sözleşme testinin tam Uçtan Uca entegrasyon testine göre temel avantajı nedir?

Karmaşık ve kırılgan çok servisli staging ortamlarına ihtiyaç duymadan hızlı ve izole CI birim testlerinde uyumluluğu doğrular.
Q2

`pact-broker can-i-deploy` komutu neyi doğrular?

Servisin belirli bir sürümünün, hedef ortamda çalışan tüm tüketici ve sağlayıcıların tam sürümleriyle başarıyla doğrulanıp doğrulanmadığını.

Tüketici Odaklı Sözleşme Testleri ve Pact — Sıkça Sorulan Sorular

Ödeme Sağlayıcı ekibi API yanıtındaki `user_id` alanını `customer_id` olarak değiştiriyor. Tüketici Odaklı Sözleşme testi devredeyse bu kırıcı değişiklik ne zaman yakalanır?

Ödeme Sağlayıcısının kendi pull request CI derlemesinde, tüketici sözleşmelerine karşı Pact doğrulaması çalışırken. Sağlayıcının CI boru hattı tüketicinin sözleşmesini çalıştırır. Sözleşme `user_id` beklediği için sağlayıcı derlemesi PR birleşmeden önce anında hata verir.

Neden bir tüketici sözleşmesi sağlayıcının tüm JSON şemasını değil, YALNIZCA aktif olarak kullandığı alanları doğrulamalıdır?

Sağlayıcı bu tüketicinin hiç kullanmadığı alanları değiştirdiğinde veya kaldırdığında yalancı derleme hatalarını önlemek için. Sözleşmeleri yalnızca tüketilen alanlarla sınırlamak sağlayıcının şema evrimini korur; sağlayıcı kimsenin kullanmadığı alanları güvenle kaldırabilir.

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

Temel Gerçekler & İlkeler

  • ▸Tüketici Odaklı Sözleşme (CDC) testleri, API tüketicilerinin ihtiyaç duydukları kesin alan ve uç noktaları çalıştırılabilir sözleşmeler (Pact) olarak tanımlamasını sağlar; sağlayıcılar bu sözleşmeleri CI sürecinde doğrulayarak canlıda kırıcı değişiklikleri önler.
  • ▸Tüketici Odaklı Sözleşme testi, API tüketici beklentilerinin resmi sözleşmelere dönüştürüldüğü ve API sağlayıcıları tarafından izole birim test süreçlerinde bağımsız olarak doğrulandığı bir test metodolojisidir.

Yaygın Yanılgılar

  • ✗Staging ortamında aynı anda 50 mikroservisin ayağa kalkmasını gerektiren hantal uçtan uca testler yazmak.

Karar Kılavuzu & Önceliklendirme

CDC testleri kırılgan staging entegrasyon ortamlarına olan ihtiyacı ortadan kaldırırken, yeni bir sağlayıcı sürümünün canlıdaki tüketicileri bozmayacağına dair kesin mühendislik güvencesi sunar.

Doğrulanmış Kaynaklar & Referanslar

İlgili Kavramlar

https://tinycto.tv/topics/software-architecturehttps://tinycto.tv/incidentpedia