Question 1

Bir test, geçersiz bir e-posta formatıyla POST /accounts gönderiyor ve şunu alıyor: Bu response, API testi açısından neden kötü tasarlanmış?

Accepted Answer

Doğru cevap: 200 status, önce status'e bakan her istemciye başarı der; hata body'nin içinde gizli kalır. Birçok istemci (ve basit monitoring) önce status code'a göre dallanır; 200 "bu işe yaradı" der, body'ye inmeyen bir istemci reddedilmiş, geçersiz bir isteği başarı sanır. Çözüm, gerçekte olanla eşleşen bir 4xx status'tür (örn. 400/422), üzerine body'deki detay eklenir. "error" kelimesinden kaçınmak (b) kozmetiktir ve alakasızdır, sahte bir placeholder id (c) başarısızlığı başarıya daha da çok benzetir, hata detayının body'de olması header'lardan bağımsız olarak doğaldır (d).

Question 2

Bir test, yalnızca bir bildirim servisinin başarı döndürdüğünü değil, gerçekten doğru alıcıyla tam olarak bir kez çağrıldığını da doğrulamak istiyor. Hangi test double türü buna uygundur ve neden?

Accepted Answer

Doğru cevap: Mock — çünkü mock, testin etkileşimin kendisini (bir kez, beklenen alıcıyla çağrıldı mı) iddia etmesine izin verir. Bu gereksinim, yalnızca hazır bir sonuç sağlamak değil davranış doğrulamasıdır (çağrı yapıldı mı, kaç kez, hangi argümanlarla) — mock'un tam olarak var olduğu yer burasıdır. Düz bir stub (a) yanıt döndürür ama çağrı-sayısı ve argüman kontrollerini testin iddialarının parçası yapmak için tasarlanmamıştır. Gerçek servis (b), kendi kodunuzun ona hangi argümanları geçtiğini doğrulamak için gerekli değildir, manuel log kontrolü (d) aynı şey otomatik ve tekrarlanabilir şekilde iddia edilebiliyorken gereksizdir.

Question 3

Bir test bir kaynak oluşturuyor, kontrol ediyor ve hiç silmiyor. Paylaşımlı test ortamında yüz kez çalıştırılınca kaynak listesi binlerce kayda çıkıyor ve alakasız bir GET /resources testi timeout vermeye başlıyor. Altta yatan sorun nedir?

Accepted Answer

Doğru cevap: Oluşturan test temizlik yapmadan veri bırakıyor; kalan veri paylaşımlı ortamı diğer testler için kirletiyor. Veri oluşturan ama hiç kaldırmayan bir test, paylaşımlı ortamda kalıcı bir kalıntı bırakır; çok sayıda çalıştırmada bu kalıntı birikir ve orijinal testle hiçbir ilgisi olmayan testleri etkilemeye başlar — testlerin düzgün izole ve kendi kendini temizleyen olmamasının bir belirtisi. Çözüm, her çalıştırma sonrası oluşturulanı kaldırmak (ya da özel, tek kullanımlık veri kullanmak)tır. Listeleme endpoint'i gerçekten daha büyük bir veri kümesi altında yavaşladığı için mutlaka hatalı değildir (a), daha fazla bellek (b) aynı birikimi yalnızca erteler, buna göz yummak (c) tam olarak kaçınılması gereken pratiktir.

Question 4

Bir response'un şu kuralları sağlaması bekleniyor: id bir integer, name boş olmayan bir string, price sıfırdan büyük bir sayı. Şu response verildiğinde:

{"id": "7", "name": "", "price": 12.5}

Bu response'un schema validation'ı hakkında hangi ifade doğrudur?

Accepted Answer

Doğru cevap: Response başarısız olur, çünkü id integer yerine string ve name boş-olmayan yerine boş. Belirtilen kurallara göre aynı anda iki şey yanlıştır: id, integer yerine "7" string'i olarak geliyor, ve name boş bir string — "boş olmayan"ı sağlamıyor. Bir schema validator varsayılan olarak sessizce tip dönüştürmez (a) — bu gerçek bir tip uyumsuzluğunu gizlerdi — ve schema validation genel olarak yapı ve tip kısıtlarını kontrol eder, yalnızca sayısal aralıkları değil (b); listelenen ihlallerin ikisi de gerçektir, yalnızca biri değil (d).

Question 5

Bir backend, mevcut bir response'a yeni bir opsiyonel alan (discountCode) ekliyor. Consumer'ın testleri, bilinmeyen alanları geçersiz sayan bir schema ile yazılmış (additionalProperties: false ya da eşdeğeri). Ne olur ve bu ne ortaya koyar?

Accepted Answer

Doğru cevap: Consumer'ın testleri tamamen katkısal bir değişiklikte başarısız olur; schema'nın amaçlanandan daha katı olduğunu ortaya koyar. Zaten bilmediği herhangi bir alanı reddeden bir schema, zararsız, katkısal bir değişikliği kırılma gibi ele alır — buradaki versiyon uyumluluğu sorunu API değişikliğinde değil, testin kendi katılığındadır. Schema'yı bilinmeyen ekstra alanlara izin verecek (ve onları basitçe yok sayacak) şekilde gevşetmek, gerçekten uyumlu değişikliklerin geçmesini sağlarken eksik ya da yanlış tipte zorunlu bir alan gibi gerçek sözleşme ihlallerini yakalamaya devam eder. Schema validation, öyle yapılandırıldığında beklenmedik ekstra alanları kesinlikle işaretleyebilir (b), opsiyonel bir alan eklemek katkısaldır, doğası gereği breaking değildir (c), bir schema consumer'ın bir alanı kendiliğinden tüketmeye başlamasına yol açmaz (d).

Question 6

Bir test suite'i testler sabit alfabetik sırada çalıştığında geçiyor ama birçok CI aracının flaky testleri ortaya çıkarmak için kullandığı rastgele sırada çalıştığında başarısız oluyor. Her test tek başına sorunsuz geçiyor. Bu en güçlü şekilde neyi işaret eder?

Accepted Answer

Doğru cevap: Bazı testler, alfabetik olarak önce çalışan testlerden kalan state'e bağımlı. Sabit bir sırada geçip rastgeleleştirmede başarısız olmak, her test tek başına sorunsuzken, araç arızasından çok bir sıra-bağımlılığı bug'ının imzasıdır. a aracın bozuk olduğunu varsayıyor ki bu gerçek bir bağımlılıktan çok daha az olası; b ve d neden özellikle sıranın önemli olduğunu açıklamıyor.

QA / Test Otomasyonu Senior Mülakat Soruları

Örnek sorular

Konular

Kıdeme göre

Diğer alanlar