Örnek sorular
Sd Test Framework DesignZorluk 1
En basit anlamda, düz bir betik dilinin tek başına yapamayacağı, bir test framework'ünün sorumlu olduğu şey nedir?
- aTestlerin çalıştıracağı production kodunu yazmak
- bTest case'leri keşfetmek, onları tutarlı bir şekilde çalıştırmak ve pass/fail sonuçlarını raporlamak✓
- cTestler geçtikten sonra uygulamayı bir production sunucusuna deploy etmek, yeni sunucuları hazırlamak ve deployment kimlik bilgilerini döndürmek dahil
- dGeliştiricilerin herhangi bir assertion yazmasına gerek bırakmamak
Açıklama:Bir test framework'ünün temel işi keşif (test fonksiyonlarını/sınıflarını bulmak), çalıştırma (setup/teardown ile tutarlı biçimde çalıştırmak) ve raporlamadır (pass/fail sonuçlarını toplayıp sunmak) — bu (b). Framework'ler production kodu yazmaz (a), deployment ile ilgilenmez (c), ve geliştiricilerin yine de kendi assertion'larını yazmasını gerektirir (d).
Sd Test Framework DesignZorluk 1
Bir test framework'ü içindeki assertion library'sinin temel amacı nedir?
- aGerçek bir değeri beklenen bir değerle karşılaştırmak ve eşleşmediklerinde net bir hata fırlatmak✓
- bBir testi geçene kadar otomatik olarak yeniden denemek
- cHer test çalıştırması için rastgele test verisi üretmek
- dEntegrasyon testlerinin kullandığı veritabanı bağlantılarını yönetmek, bağlantı havuzlarını açmak ve test çalıştırmaları arasında kimlik bilgilerini döndürmek dahil
Açıklama:Assertion library'sinin işi gerçek değeri beklenen değerle karşılaştırmak ve eşleşmediğinde neyin yanlış gittiğini açıkça anlatan bir hata fırlatmaktır — bu (a). Testleri yeniden deneme (b), rastgele veri üretme (c) ve DB bağlantısı yönetimi (d) bir test yığınının başka parçalarının işidir.
Sd Test Framework DesignZorluk 2
pytest'te, db_connection adında @pytest.fixture ile dekore edilmiş bir fonksiyon, bir test tarafından sadece test fonksiyonuna db_connection adında bir parametre eklenerek istenir. Bunu çalıştıran mekanizma nedir?
- apytest test dosyasının import'larını tarar ve bunları fixture adlarıyla alfabetik eşleştirir
- bFixture'ın çalışması için testin gövdesinde
db_connection() fonksiyonunu manuel çağırması gerekir - cpytest test fonksiyonunun parametre adlarını inceler ve eşleşen fixture'ın return/yield değerini enjekte eder✓
- dFixture'lar sadece
conftest.py içindeki bir __all__ değişkeninde açıkça listelenmişse kullanılabilir
Açıklama:pytest'in fixture sistemi parametre adlarına dayalı dependency injection ile çalışır: bir test fonksiyonunun imzasını inceler, kayıtlı fixture adlarıyla eşleşen parametreleri bulur ve her fixture'ın return (veya yield edilen) değerini otomatik enjekte eder — bu (c). Import'a dayalı bir eşleştirme yoktur (a), pytest fixture'ı kendisi çağırdığı için manuel çağrı gerekmez (b), ve fixture'lar conftest.py'de bir __all__ listesi gerektirmez (d).
Sd Test Framework DesignZorluk 2
Bir takım, sadece if actual != expected: raise AssertionError() yapan, mesajsız kendi assertEqual(actual, expected) assertion yardımcısını yazıyor. Bu neden zayıf bir assertion library tasarımıdır?
- aÇünkü
!= hiçbir programlama dilinde iki tamsayıyı karşılaştıramaz, çünkü karşılaştırma operatörleri sadece string'ler ve kayan noktalı değerler için tanımlıdır - bÇünkü
AssertionError fırlatmak hiçbir test runner tarafından desteklenmez - cÇünkü değerler gerçekten farklı olduğunda sessizce geçer
- dÇünkü bir hata, gerçek ve beklenen değerlerin ne olduğu hakkında hiçbir bilgi vermez, bu da debug'ı zorlaştırır✓
Açıklama:İyi bir assertion library'sinin temel değerlerinden biri, geliştiricinin print ifadesi eklemeden debug edebilmesi için gerçek ve beklenen değerleri gösteren tanısal bir hata mesajıdır — boş bir AssertionError() bu bilgiyi tamamen kaybeder, bu (d). Tamsayı karşılaştırmasında != düzgün çalışır (a), AssertionError çoğu runner'ın tanıdığı standart istisnadır (b), ve kontrol gerçek bir uyuşmazlıkta doğru şekilde başarısız olur (c).
Sd Test Framework DesignZorluk 2
JUnit 5'te bir Extension'ın (örn. BeforeEachCallback uygulayan bir sınıfın) rolü nedir?
- aTest sınıfının kendisini değiştirmeden, her test metodundan önce kod çalıştırmak gibi özel davranışı test yaşam döngüsüne eklemek✓
- bHerhangi bir test metodunda
@Test annotation'ı yazma gereğini ortadan kaldırmak, çünkü extension'lar bir sınıftaki her metodu otomatik olarak keşfedip çalıştırılabilir bir test case olarak kaydeder - cSadece test çıktısının konsol rengini değiştirmek için kullanılır
- dTest sınıflarını çalıştırmadan önce bytecode'a derlemek
Açıklama:JUnit 5'in extension modeli, extension arayüzlerini uygulayarak test sınıfının gövdesine dokunmadan yeniden kullanılabilir davranışı (her testten önce/sonra, tüm testlerden önce/sonra, parametre çözümleme vb.) test yaşam döngüsüne eklemenizi sağlar — bu (a). Extension'lar @Test gerekliliğini kaldırmaz (b), sadece konsol rengiyle sınırlı değildir (c), ve bytecode derlemesinde rolü yoktur (d).
Sd Test Framework DesignZorluk 1
Bir test runner'ının "discovery" (keşif) aşaması tipik olarak ne yapar?
- aÖnceki test çalıştırmasının ne kadar sürdüğünü ölçer ve bu geçmiş süreye dayanarak bir sonraki çalıştırma için timeout'u otomatik ayarlar
- bBaşarısız testlerin bulduğu bug'ları otomatik olarak düzeltir
- cKod tabanını tarayarak framework'ün test-adlandırma kuralına uyan dosyaları, sınıfları veya fonksiyonları bulur✓
- dTest sonuçlarını bir bulut dashboard'ına yükler
Açıklama:Discovery, bir runner'ın ne çalıştıracağını bilmek için kod tabanını adlandırma kuralına (örn. test_ ile başlayan dosyalar, test önekli fonksiyonlar, @Test işaretli sınıflar) uyan öğeler için taradığı aşamadır — bu (c). Zamanlama (a), bug'ları otomatik düzeltme (b) ve dashboard'a yükleme (d) discovery'nin dışında ayrı, opsiyonel konulardır.