Test piramidi, otuz yıldır varsayılan yanıt: "çok birim testi, az entegrasyon, daha az uçtan uca." Bu oran bir doğa kanunu değil, bir başlangıç tahminidir.
Modern ön yüzlerde bu tahmin çoğu zaman yanlışlaşır. React, derin bileşen ağaçları, istemci tarafında veri önbellekleme ve asenkron yükleme — hepsi, "birim testi yeterlidir" varsayımını bozdu. Bir bileşen, kendi halinde doğru çalışıyor olabilir; bileşenler birlikte olduğunda bozulabilir.
Bu yazı, katmanları nasıl yerleştireceğinizi anlatıyor.
Üç katman, üç farklı soru
Birim testi: "Bu fonksiyon doğru mu?" Tek bir bileşen, tek bir fonksiyon. Hızlı, ucuz, yoğun.
Entegrasyon testi: "Bu bileşen doğru veriyle doğru davranıyor mu?" Bileşen
- veri kaynağı. Burada hataların çoğu yakalanır.
Uçtan uca test: "Kullanıcının yolu gerçekten çalışıyor mu?" Tarayıcıda, gerçek akışta. Yavaş, pahalı, ama sayısı az olmalı.
Kural şu: birim testi "işlevi", uçtan uca test "yolculuğu" doğrular. Bunlar birbirinin yerine geçmez, birbirini tamamlar.
Neden piramit çoğu zaman yanlış
Piramidin önerdiği oran — çok birim, az uçtan uca — şu varsayıma dayanır: iş mantığı bileşenin içindedir ve bileşenler birbirinden bağımsız çalışır.
Modern ön yüzlerde bu doğru değildir:
Durum yönetimi bileşenin dışındadır. Bir bileşen doğru render olabilir, veri gelmemiş olabilir. Bileşen testi bunu yakalamaz.
Stil bağlamdan gelir. Bir buton doğru davranabilir, üstteki kaplama yüzünden tıklanamaz olabilir.
Yükleme durumları ayrı ekrandır. Boş durum, hata durumu, yavaş bağlantı durumu. Üçü de ayrı arayüz; hiçbiri "bileşen doğru render ediyor" testinin kapsamında değil.
Zaman ve asenkronluk. Bir hata, yanlış zamanda gelen bir yanıtta olabilir. Test bunu deterministik yapamazsa, yakalayamaz.
Bu yüzden modern projelerde entegrasyon testleri birim testlerinden daha değerlidir, ve bu çoğu ekipten duyulmayan bir gerçektir.
Kupa modeli ve sınırları
"Kupa" modeli, test sayısını değil değerini öne çıkarır: az sayıda yüksek değerli test, çok sayıda düşük değerli testten iyidir.
Bu yönüyle doğru. Yanlış anlaşılan yönü şu: kupa, "birim testi yazma" demek değildir. Kupa, yazılan her testin bir karar taşıması gerektiği anlamına gelir.
"Bir fonksiyon 3 ve 5 döndürür" testi bir karar taşımaz — kodu zaten söylüyor. "Ödeme adımında fiyat metni görünmezse hata verir" testi taşır.
Pratik uygulama: birim testi yazmadan önce sorun — bu test kırılırsa ne değişir? Cevap "hiçbir şey, kod zaten öyle" ise yazmayın.
Katmanları nasıl dağıtmalı?
Önerilen çalışma oranı — kendi projenize göre ayarlayın:
Entegrasyon: %50-60. Asıl yük burada. Bileşen gerçek veriyle, gerçek durumlarla. Kritik yollar bu katmanda.
Uçtan uca: %10-20. Sadece para veya itibar etkileyen yollar. Kayıt, giriş, ödeme, kritik formlar.
Birim: %25-35. Hesaplama, dönüştürme, doğrulama mantığı. Saf fonksiyonlar.
Bu oran piramidin aynadır ve ters çevrilmiştir. Piramit değişmez, ağırlığı değişir.
Ekipte benimseme
Strateji değişikliği, test değişikliğinden zordur. Pratikte şu sırayla işe yarar:
1. Var olan testleri taşımayın. Testlerin çoğu gerçekten değerlidir; yalnız yanlış katmanda. Taşımak yerine, yeni yazılan testleri doğru katmanda yazın.
2. Yeni kapsamı doğru yere yazın. Yeni bir yazı ekliyorsanız, ilk testinizi entegrasyon olarak yazın. Bu tek kural, altı ayda piramidi kendiliğinden tersine çevirir.
3. Kırıklardan sonra test yazın. Bir hata buldunuz ve düzelttiniz. Şimdi o davranışı doğrulayan bir test yazın. Bu testlerin kalıcılığı en yüksek olanlardır, çünkü gerçek bir kırılmadan doğmuşlardır.
4. Kapsamı ölçün, tahmin etmeyin. Hangi katmanda kaç test var? Bu bir varsayım değil, veri. Ekipteki tartışma genellikle bu sayıyla çözülür.
Görsel test bu dengeye nereye oturur?
Görsel karşılaştırma, katmanlar arasında durmaz. Onu ayrı ele almak gerekir, çünkü test ettiği şey diğerlerinden farklıdır:
- Birim ve entegrasyon testleri mantığı doğrular.
- Görsel karşılaştırma sunumu doğrular.
İkisi birbirinin yerine geçmez. Düğmenin onClick'i doğru bağlı olabilir ve
buton görünmez olabilir. Bu, yazılım testlerinin geçtiği ama sayfanın bozuk
göründüğü bir durumdur.
Görsel testin katmanları içindeki yeri, CI hattının en dar kapısıdır — yani uçtan uca. Ama kapsamı çok daha dardır: on kritik sayfa, hepsi değil.
Hat kurulumu için CI/CD kılavuzuna, karşılaştırmanın çalışma mantığı için görsel regresyon testi yazısına bakın.
Özet
- Piramit bir kural değil, bir başlangıç tahminidir; modern ön yüzlerde ağırlığı ters çevrilmiştir.
- Bileşen doğru render olabilir, yolculuk yine bozuk olabilir. Bu yüzden entegrasyon testleri daha değerlidir.
- Entegrasyon ağırlıklı, uçtan uca dar, birim orta bir dağılım işe yarar.
- Kupa modelinin getirdiği asıl kural: her test bir karar taşımalı.
- Görsel test sunumu doğrular, mantığı değil; bu yüzden ayrı ele alınır.
- Ekipte benimsemenin en ucuz yolu: yeni testleri doğru katmana yazmak.