Sözleşme Testleri — Karşı Servis Değişince Kim Kırı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.
-
Bayt: Havale servisinin bütün testleri yeşil. Hesap servisini mock'ladık, her şey yolunda!
-
Sen: Bu sabah canlıda havale ekranı çöktü. Biz kodumuzu hiç değiştirmedik.
-
Bayt: Hesap servisi dün balance alanının adını değiştirmiş... mock'umuz eski adı kullanıyormuş.
-
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.
Elle yazılmış bir mock karşı servisin değişikliğini neden fark etmez?
Hesap servisi balance alanının adını değiştirdi; havale servisinin testleri mock'larla yazılmış. Ne olur?
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.
Adım adım oku
- Fiş iki pimi kullanıyor.
- Prize delik eklemek kimseyi bozmaz.
- Kullanılan pimi kaydırmak fişi bozar.
- 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.
Tüketici odaklı sözleşmede sözleşmeyi kim yazar?
Sağlayıcı sözleşmeyi ne zaman doğrular?
Kendin gör
Karşı servis değişince kim kırılır?
Tohum 695210Havale 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.
Ş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.
- Varsayılanla oynat. Elle yazılmış mock’lar: iki kırıcı değişiklik de canlıya çıktı.
- “Uçtan uca testler” seç. Kırılmalar yakalandı, ama değişiklikler birleştirilip ortama çıktıktan sonra.
- “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.
- “Tüketici odaklı sözleşme testleri” seç. Kırıcılar sağlayıcının build’inde durdu, güvenliler geçti.
Hesap servisi, hiçbir tüketicinin okumadığı branchCode alanını kaldırdı. Tüketici odaklı sözleşme testleri ne yapar?
Bütün cevap şemasını koruyan bir testin sorunu nedir?
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.
Tüketici, okumadığı alanları da sözleşmeye yazdı. Ne olur?
Derinleş · Havale ve hesap servisleri: Pact ile tüketici odaklı sözleşme 3 dosya · ~54 satır · ilk okumada atlayabilirsin
Kendini sına
Elle yazılmış mock'larla geçen testler, karşı servisin bugünkü cevabıyla uyumlu olduğunu kanıtlar.
Sözleşmeler yazılmış ama hiçbir pipeline'da doğrulanmıyor. Ne olur?
Aklında kalacak üç şey
- 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 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 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.
4 kart sonraki derste seni bekliyor