Örnek sorular
Sd Contract TestingZorluk 1
Consumer-driven contract testing'in temel fikri nedir?
- aProvider ekibi consumer'ın gönderebileceği her alanı yazar ve tüm consumer'ları buna birebir uydurur
- bBir test uzmanı canlı bir provider'a karşı consumer uygulamasında manuel olarak gezinip hiçbir şeyin bozulmadığını doğrular, bu adımları her release öncesinde elle tekrar eder
- cConsumer, provider'dan beklediği etkileşimleri tanımlar; provider da bu beklenti setini karşılayabildiğini doğrular✓
- dProvider, yanıt gecikmesini ölçmek için production trafiğini bir staging ortamına karşı tekrar oynatır
Açıklama:Consumer-driven contract (CDC) testing'de consumer, göndereceği istekleri ve beklediği yanıtları belirtir; provider da aynı beklenti setine karşı doğrulama yapar — bu (c). Provider'ın şemayı dikte etmesi (a) ilişkiyi tersine çevirir, manuel UI gezinme (b) keşifsel test'tir, trafik tekrar oynatma (d) ise performans testidir, contract testing değildir.
Sd Contract TestingZorluk 1
Contract testing terminolojisinde "pact" (kontrat) nedir?
- aİki mühendislik yöneticisi arasında release tarihleri hakkında imzalanmış bir hukuki belge
- bBelirli bir consumer ile belirli bir provider arasındaki beklenen request/response etkileşimlerinin kaydedildiği bir küme✓
- cHer mikroservisi kapsayan tam kullanıcı yolculuğunu çalıştıran tek bir uçtan uca test
- dBir provider'ın saniyede alabileceği istek sayısını sınırlayan ve provider'ın load balancer'ı tarafından otomatik uygulanan bir performans bütçesi
Açıklama:Pact, consumer'ın provider'dan beklediği etkileşimleri (göndereceği istekler ve bekleyeceği yanıtlar) kaydeden bir artefakttır (genelde bir JSON dosyası) — bu (b). Hukuki belge (a), tam uçtan uca test (c) ya da performans bütçesi (d) değildir.
Sd Contract TestingZorluk 1
Contract testing'de kullanılan consumer/provider terminolojisinde roller hangi ifadeyle doğru tanımlanır?
- aConsumer her zaman bir frontend UI'dır, provider ise her zaman bir veritabanıdır
- bConsumer, bir çağrı yapan servistir; provider ise bu çağrıyı alıp yanıtlayan servistir✓
- cConsumer ve provider aynı servisin iki farklı adıdır, o anda hangi ekibin paylaşılan repo'yu sahiplendiğine göre seçilir
- dProvider test kodunu yazan taraftır, consumer ise sadece sonuçları okur
Açıklama:Consumer, bir API'yi çağıran her şeydir (bir frontend, başka bir backend servisi, mobil uygulama vb.); provider ise o API'yi açığa çıkarıp yanıtlayan taraftır — bu (b). Roller UI-veritabanı ayrımına bağlı değildir (a), aynı servisin iki adı değildir, ayrı servislerdir (c), ve her iki taraf da kendi testini yazar (d).
Sd Contract TestingZorluk 1
Contract testing, tam uçtan uca entegrasyon testinden ayrı bir pratik olarak neden var?
- aUnit testleri tamamen ortadan kaldırır, çünkü unit testler entegrasyon sorunlarını yakalayamaz
- bHerhangi bir public REST API sunan sistem için yasal bir zorunluluktur
- cProvider'ın iş mantığının her girdi için doğru sonuç ürettiğini garanti eder ve böylece her türlü fonksiyonel testi gereksiz kılar
- dTakımların, her servisi bir arada ayağa kaldırmadan consumer ile provider'ın bir API'nin şekli üzerinde anlaştığını doğrulamasını sağlar✓
Açıklama:Contract testing, gerçek servisleri bir arada çalıştırmaya gerek kalmadan entegrasyon uyuşmazlıklarını erken yakalamak için vardır — bu (d). Unit testlerin yerini almaz (a), yasal bir zorunluluk değil mühendislik pratiğidir (b), ve iş mantığının doğruluğunu değil API'nin request/response şeklini kontrol eder (c).
Sd Contract TestingZorluk 2
Bir platformda 6 consumer servis, 5 farklı provider servisi çağırıyor. Her consumer-provider çiftinin, gerçek deploy edilmiş örneklere karşı çalışan kendi özel tam uçtan uca entegrasyon test suite'ine ihtiyacı olsaydı, bu hangi sorunu gösterir?
- aHer isteğin fazladan bir veritabanı gidiş-dönüşü tetiklediği N+1 query sorunu
- bTestlerin zamanlama sorunları yüzünden aralıklı olarak başarısız olduğu flaky test sorunu
- cTest suite sayısının her consumer-provider kombinasyonuyla birlikte büyüdüğü N×M entegrasyon testi patlaması✓
- dBir testin arta kalan verisinin, ilgisiz başka bir testin beklenen başlangıç durumunu bozduğu test verisi kirlenmesi sorunu
Açıklama:Bu, N×M patlamasıdır: N consumer ve M provider varken naif bir yaklaşım en fazla N×M özel entegrasyon suite'i gerektirir ve her yeni servis maliyeti çarpar — bu (c). N+1 query (a) bir veritabanı performans sorunudur, flakiness (b) deterministik olmayan başarısızlıklarla ilgilidir, veri kirlenmesi (d) bir test izolasyon sorunudur — hiçbiri suite sayısındaki kombinatoryal büyümeyi tanımlamaz.
Sd Contract TestingZorluk 1
Contract testing, consumer-driven contract'ların tanımladığı N×M entegrasyon testi patlamasını azaltmaya nasıl yardımcı olur?
- aHer consumer, kontrattan üretilen hafif bir mock'a karşı test edilir; her provider da aynı kontrata karşı bağımsız olarak doğrulanır, böylece hiçbir çift için canlı birleşik ortama gerek kalmaz✓
- bProvider'ların hiç otomatik teste ihtiyacı kalmadığı anlamına gelir
- cTüm consumer ve provider'ları tek bir monolitik deploy edilebilir birime birleştirir, böylece test edilecek tek bir şey kalır
- dHer consumer ve provider'ın aynı programlama dilinde yeniden yazılmasını gerektirir
Açıklama:Contract testing iki tarafı birbirinden ayırır: consumer, kontrattan üretilen bir mock'a karşı doğrulanır, provider da aynı kontrata karşı bağımsız doğrulanır; böylece N×M canlı entegrasyon suite'i N+M kontrat doğrulamasına iner — bu (a). Provider'ın kendi test sorumluluğunu ortadan kaldırmaz (b), servisleri birleştirmeyi gerektirmez (c), dile bağımlı değildir (d).