Yazdığım tek test türü

Mühendislik dünyasında, hangi tür testlerin daha iyi olduğu hakkında neredeyse sürekli bir arka plan düzeyinde konuşma vardır; birim testleri, entegrasyon testleri, uçtan uca testler vb.

Bir süre önce, sadece bir tür test yazmaya karar verdim.

Yukarıdaki kategorilerden herhangi birine tam olarak uyduğundan emin değilim. Belki de 'entegrasyon testi' en doğru olanıdır, ancak bu onu tam olarak kapsamaz - en önemlisi, hiç kimse bu farklı etiketlerin ne anlama geldiğini gerçekten nasıl tanımlayacağı konusunda gerçekten anlaşamaz.

İşte izlediğim ilkeler:

1. Net bir ortak arayüz tanımlanmış olana kadar tek bir test yazmam.
2. Testlerim, gerçek bir kullanıcının davranışını olabildiğince yakından taklit etmelidir . Bu, yalnızca genel apis'i çağırmak veya son kullanıcı için tasarlanmış bir ön uç arabirimiyse, yalnızca bir son kullanıcının yapacağını yapmak anlamına gelir.
3. Bir işlev veya bileşen genel arayüzün parçası değilse, onu doğrudan test etmem. Bazı genel yollarla dolaylı olarak çağırmak mümkün değilse, zaten amacı tam olarak nedir?
4. Uzak ağ araması yok. Bu, localhost'a yapılan bir çağrı değilse (örneğin, yerel bir test veritabanı), alay edilmesi gerekir. Testlerim, ağ veya internet bağlantısı olmadan tutarlı bir şekilde geçmelidir.
5. Dahili kod yollarıyla dalga geçilmez. Ağ sınırında alay etmek harika, ancak test ettiğim kod tabanında var olan işlevler veya api'lerle alay etmek işe yaramaz.
6. Farklı testler arasında hiçbir durum taşınmadı. Bir test, önceki bir testin durumuna bağlıysa veya bu durumdan herhangi bir şekilde etkilenebilirse, bir şeyler ters gitti demektir. Bu, 'her testten sonra tüm durumu temizle' anlamına gelmek zorunda değildir.
7. Dahili durum testi yok. Testimde bazı dahili durumları elle başlatmam veya düzeltmem gerekirse (mevcut başka bir genel arabirim kullanmadan), testim muhtemelen iyi değil.
8. Dahili uygulama ayrıntılarının testi yok. Kodumu yeniden düzenlemek testin başarısız olmasına neden olacaksa, bu muhtemelen iyi bir test değildir.
9. Dahili işlevleri çağıran 'birim testleri' yok. Bunun gibi işlevleri test etmek için güçlü bir istek duyarsam, muhtemelen önceden kendi iş mantığımdan tamamen ayrılmış net bir arayüzle kendi bağımsız modüllerine veya paketlerine ayrılmalılar.
10. Bunu yerel ana bilgisayarımda yapmak son derece uygun olmadıkça, tam bir sunucu ve veritabanı ile birden çok hizmetin döndürülmesini ve bunların hepsinin birlikte çalıştırılmasını gerektiren 'uçtan uca' stil testleri yok.
11. 'Kod satırlarının kapsamı' yerine 'kullanım durumlarının kapsamına' odaklanıyorum.
12. Genel arayüzün nasıl görüneceği önceden çok netse, önce bir test yazın. Aksi takdirde, önce kodu yazın, sonra test edin.
13. Bir test yazmamak veya bir kullanım senaryosunu denenmemiş bırakmaktan daha iyi olduğunda yukarıdaki kurallardan herhangi birini çiğniyorum.