İçeriğe geç

Sözleşme Testleri — Karşı Servis Değişince Kim Kırılır?

Orta 9 dk Sık karşılaşılır

Önce şunu oku: Test Piramidi, JUnit 5 ve Mockito

30 saniyede özet

Bir servis başka bir servisin cevabını okuyorsa, karşı tarafın değişikliği onu kırabilir. Mock'lar bunu göremez, uçtan uca testler geç görür. Tüketici odaklı sözleşme testi, tüketicinin neyi okuduğunu sağlayıcının her build'inde doğrular.

Bir elektrikli cihaz üretiyorsun ve fişin iki pimi var. Priz üreten firma bir gün yeni bir delik ekliyor; sorun yok. Ama bir ertesi gün pimlerden birinin yerini değiştiriyor ve senin cihazın hiçbir prize oturmuyor.

  1. Bayt: Havale servisinin bütün testleri yeşil. Hesap servisini mock'ladık, her şey yolunda!

  2. Sen: Bu sabah canlıda havale ekranı çöktü. Biz kodumuzu hiç değiştirmedik.

  3. Bayt: Hesap servisi dün balance alanının adını değiştirmiş... mock'umuz eski adı kullanıyormuş.

  4. Bayt: Mock, onların bugün ne gönderdiğini bilmiyor. Bunu kimin, ne zaman yakalaması gerekirdi?

Mock neyi göremez?

Havale servisi hesap servisinden bakiyeyi okur; testlerde de hesap servisini elle yazılmış bir mock ile taklit ederiz. Bu testler hızlıdır ve kendi kodumuzu sınar.

Ama mock, karşı servisin dün ne gönderdiğini taklit eder. Hesap servisi bir alanın adını değiştirirse, mock’lu testler geçmeye devam eder ve kırılma ancak canlıda görünür.

Kafam karıştı, daha basit anlat

Mock karşı servisin eski hâlini taklit eder; değiştiğinde haberi olmaz.

Hızlı kontrolBaşlangıç

Elle yazılmış bir mock karşı servisin değişikliğini neden fark etmez?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

Hesap servisi balance alanının adını değiştirdi; havale servisinin testleri mock'larla yazılmış. Ne olur?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

Sözleşmeyi kim yazar, kim doğrular?

Hesap servisi, havale servisinin hiç okumadığı branchCode alanını kaldırdı. Bütün cevap şemasını koruyan bir test bu değişikliği ne yapar? Cevabı göster

Durdurur, gereksiz yere. Şema değiştiği için test kırılır; oysa hiçbir tüketici bu alanı kullanmıyordu. Böyle alarmlar çoğalınca ekip onları görmezden gelmeye başlar.

Fişin şekli prizi yapana verilir: sözleşme.
Adım adım oku
  1. Fiş iki pimi kullanıyor.
  2. Prize delik eklemek kimseyi bozmaz.
  3. Kullanılan pimi kaydırmak fişi bozar.
  4. Fişin şekli prizi yapana verilir: sözleşme.

sözleşme testiİki servisin birbirinden ne beklediğini otomatik olarak kontrol eden test. Karşı servisin değişikliği seni kırıyorsa, canlıya çıkmadan söyler.Sözlükte gör →, iki servisin birbirinden ne beklediğini otomatik olarak kontrol eder. tüketici odaklı sözleşmeSözleşmeyi karşı servisi kullanan tarafın yazdığı yaklaşım: yalnızca okuduğu alanlar. Sağlayıcı her build'inde onu doğrular.Sözlükte gör → sözleşmeyi tüketici yazar: “bu istekte bana şu alanlar, şu tiplerle gelsin.”

Sağlayıcı bu sözleşmeyi her build’inde kendi gerçek koduna karşı çalıştırır. Tüketicinin okuduğu bir alanı bozan değişiklik birleştirilmeden durur; kimsenin okumadığı alanlara dokunmak serbesttir.

Kafam karıştı, daha basit anlat

Tüketici neyi okuduğunu yazar, sağlayıcı her build’de bunu doğrular.

Hızlı kontrolOrta

Tüketici odaklı sözleşmede sözleşmeyi kim yazar?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

Sağlayıcı sözleşmeyi ne zaman doğrular?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

Kendin gör

Karşı servis değişince kim kırılır?

Tohum 695210

Havale servisi, hesap servisinin cevabından yalnızca balance ve currency alanlarını okuyor.

    Oynat ya da adımla: her adımda sağlayıcı bir değişiklik yapar.

    Hız
    Adım 0

    Şu an ne oldu?

    Elle yazılmış mock’lar

    Hesap servisi dört değişiklik yapacak; ikisi havale servisini kırar, ikisi kırmaz.

    Görevler0/3

    • Kırıcı bir değişikliği canlıya kaçıraçık

      İpucu

      Varsayılan ayarlar yeter.

    • Güvenli bir değişikliği gereksiz yere durduraçık

      İpucu

      Her şeyi koru.

    • Kırıcıları birleştirmeden önce durdur, güvenlileri geçiraçık

      İpucu

      Tüketici neyi okuduğunu söylesin.

    Olay günlüğü (0)

    Henüz olay yok. Oynat veya adımla.

    1. Varsayılanla oynat. Elle yazılmış mock’lar: iki kırıcı değişiklik de canlıya çıktı.
    2. “Uçtan uca testler” seç. Kırılmalar yakalandı, ama değişiklikler birleştirilip ortama çıktıktan sonra.
    3. “Bütün şemanın anlık görüntüsü” seç. Kırıcılar erken durdu, ama iki güvenli değişiklik de gereksiz yere durdu.
    4. “Tüketici odaklı sözleşme testleri” seç. Kırıcılar sağlayıcının build’inde durdu, güvenliler geçti.
    Hızlı kontrolOrta

    Hesap servisi, hiçbir tüketicinin okumadığı branchCode alanını kaldırdı. Tüketici odaklı sözleşme testleri ne yapar?

    Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

    Bütün cevap şemasını koruyan bir testin sorunu nedir?

    Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

    Tuzaklar

    Sözleşmeye her alanı yazmak: tüketici okumadığı alanları da sözleşmeye koyarsa, sağlayıcı yine gereksiz yere kırılır. Sözleşmede yalnızca gerçekten kullandığın alanlar olsun.

    Doğrulamayı sağlayıcının build’ine bağlamamak. Sözleşme yazılıp hiçbir pipeline’da çalışmazsa hiçbir şeyi korumaz. Sağlayıcı her build’inde tüketicilerin sözleşmelerini doğrulamalı.

    Uçtan uca testleri tamamen bırakmak. Sözleşme iki servisin konuşmasını sınar, bütün akışı değil. Az sayıda kritik akış için uçtan uca test yine değerlidir.

    Kafam karıştı, daha basit anlat

    Yalnızca kullandığını yaz, doğrulamayı build’e bağla, kritik akışları yine uçtan uca dene.

    Hızlı kontrolOrta

    Tüketici, okumadığı alanları da sözleşmeye yazdı. Ne olur?

    Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.
    Derinleş · Havale ve hesap servisleri: Pact ile tüketici odaklı sözleşme 3 dosya · ~54 satır · ilk okumada atlayabilirsin
    Proje dosyaları

    transfer-service/src/test/java/com/bank/transfer/ AccountsClientPactTest.java Tüketici testi: havale servisi, hesap servisinden yalnızca okuduğu iki alanı istiyor; test sahte bir sunucuya karşı çalışıyor ve sözleşme dosyasını üretiyor.

    transfer-service/src/test/java/com/bank/transfer/AccountsClientPactTest.java
    @ExtendWith(PactConsumerTestExt.class)
    @PactTestFor(providerName = "accounts-service")
    class AccountsClientPactTest {
    @Pact(consumer = "transfer-service")
    RequestResponsePact balanceOfTr01(PactDslWithProvider builder) {
    return builder
    .given("account TR01 exists")
    .uponReceiving("a balance request")
    .path("/accounts/TR01/balance").method("GET")
    .willRespondWith().status(200)
    .body(new PactDslJsonBody()
    .decimalType("balance", 1500.00) // only what the transfer service reads
    .stringType("currency", "TRY"))
    .toPact();
    }
    @Test
    void readsTheBalance(MockServer server) {
    var client = new AccountsClient(RestClient.create(server.getUrl()));
    assertThat(client.balanceOf("TR01")).isEqualTo(new Balance(new BigDecimal("1500.00"), "TRY"));
    }
    }

    accounts-service/src/test/java/com/bank/accounts/ ConsumerContractsTest.java Sağlayıcı testi: hesap servisi, gerçek koduyla tüketicilerin sözleşmelerini her build'de doğruluyor.

    accounts-service/src/test/java/com/bank/accounts/ConsumerContractsTest.java
    @Provider("accounts-service")
    @PactBroker
    @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
    class ConsumerContractsTest {
    @LocalServerPort
    int port;
    @Autowired
    AccountRepository accounts;
    @BeforeEach
    void target(PactVerificationContext context) {
    context.setTarget(new HttpTestTarget("localhost", port));
    }
    @TestTemplate
    @ExtendWith(PactVerificationInvocationContextProvider.class)
    void honoursEveryConsumer(PactVerificationContext context) {
    context.verifyInteraction(); // fails this build if a consumer's fields change
    }
    @State("account TR01 exists")
    void tr01() {
    accounts.save(new Account("TR01", new BigDecimal("1500.00"), "TRY"));
    }
    }

    accounts-service/.github/workflows/ deploy.yml (excerpt) Durum: sözleşmedeki 'hesap TR01 var' durumu sağlayıcı testinde gerçek bir kayıtla kuruluyor.

    accounts-service/.github/workflows/deploy.yml (excerpt)
    - name: Verify consumer contracts
    run: ./mvnw -B verify -Dpact.verifier.publishResults=true
    - name: Can this version be deployed?
    run: pact-broker can-i-deploy --pacticipant accounts-service --version ${{ github.sha }} --to-environment production

    Kendini sına

    Şimşek turu1/4

    Elle yazılmış mock'larla geçen testler, karşı servisin bugünkü cevabıyla uyumlu olduğunu kanıtlar.

    Soru 1/3İleri

    Sözleşmeler yazılmış ama hiçbir pipeline'da doğrulanmıyor. Ne olur?

    Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

    Aklında kalacak üç şey

    1. 1 Elle yazılmış bir mock, karşı servisin dünkü cevabını taklit eder. Karşı servis değişince mock'lu testler geçmeye devam eder ve hata canlıda çıkar.
    2. 2 Tüketici odaklı sözleşmede tüketici, karşı servisten yalnızca neyi okuduğunu yazar. Sağlayıcı her build'inde bu sözleşmeyi doğrular ve kırıcı değişiklik birleştirilmeden önce durur.
    3. 3 Bütün şemayı korumak her değişikliği durdurur, güvenlileri de. Sözleşme yalnızca kullanılan alanları kapsadığı için yalnızca gerçekten kırıcı değişikliklerde alarm verir.
    Sonraki kapı Parolayı commit'ledin, fark edince dosyayı sildin ve yeniden commit'ledin. Artık güvende misin? Sırlar — Parola Git'e Girerse Ne Olur? · 9 dk

    4 kart sonraki derste seni bekliyor

    0/4 kart bu dersten toplandı