Production Hatasını Hangi Test Engeller?
Unit ve integration testlerin gerçek getirisi: hangisinin production hatalarını gerçekten önlediği ve test bütçesinin nereye ayrılacağı.
Kısaca
Pratikte production hatalarının birçoğu bileşenlerin arasında doğar ve izole bir unit test tam da kırılan bağlantıyı mock'lar. Unit test saf, mantık yoğun çekirdekte parlar; integration test glue code'u gerçek veritabanı ve HTTP katmanıyla sınar. Test bütçesini hataların doğduğu yere ayırın, mock'u yalnızca ödeme sağlayıcısı gibi dış bağımlılıklara saklayın.
%100 unit test coverage’ı olan bir özellik, production’da ilk gün kırıldı. Hata hiçbir birimin içinde değildi; iki bileşenin birbiriyle konuşma biçimindeydi. Her birim tek tek, izole, kusursuz test edilmişti. İkisinin arasındaki dikişi ise hiçbir test görmemişti.
“Hangi test bu hatayı engellerdi?” sorusu, test stratejisinin asıl sorusudur.
Gerçek hatalar nerede doğar
Production hatalarını dürüstçe geriye doğru izlerseniz, birçoğunun aynı yerde buluştuğunu görürsünüz: bileşenlerin arası. Yanlış serialize edilmiş bir payload, uyuşmayan bir kontrat, yanlış çizilmiş bir transaction sınırı, ortamlar arası bir config farkı.
İzole unit test, tam da kırılan o parçayı mock’lar. Veritabanını mock’layan bir test, yanlış yazılmış bir sorguyu göremez. HTTP katmanını mock’layan bir test, yanlış bir status kodunu yakalayamaz. Test, gerçeğin yerine koyduğu sahte şey kadar iyidir.
Unit test ne işe yarar
Bu, unit test’e karşı bir yazı değil. Unit test’in net bir değeri var: karmaşık, saf mantık üzerinde hızlı geri bildirim. Bir hesaplama, bir algoritma, bir durum makinesi, bir sürü edge case — bunları izole, hızlı testlerle sınamak doğru hamledir. Saniyeler içinde yüzlerce senaryo.
Unit test, mantık zengin olduğunda parlar.
Integration test ne işe yarar
Integration test farklı bir soruyu cevaplar: bileşenler gerçekten birlikte çalışıyor mu? Gerçek veritabanıyla, gerçek HTTP katmanıyla, gerçek kuyrukla. Bir endpoint’e istek atıp veritabanında doğru satırın oluştuğunu doğrulamak — mock’ların gizleyeceği her şeyi açığa çıkarır.
Tipik bir web uygulaması çoğunlukla glue code’dur: veriyi al, doğrula, kaydet, döndür. Bu kodun içinde az mantık, çok bağlantı vardır. Bağlantıyı ancak integration test sınar.
Test bütçesi nereye
Klasik test piramidi en alta çok sayıda unit test koyar. Ama tipik bir web uygulaması için, hata önleme açısından en yüksek getiriyi integration testler verir — çünkü hatalar bağlantıda doğuyor.
Pratik dağılım: glue code için integration test; mantık yoğun çekirdek için unit test. Glue code’a izole unit test yığmak, coverage sayısını yükseltir ama production’ı korumaz.
Mock’un tuzağı
En sık hata, kırılan şeyi mock’lamaktır. Bir sorgunun yanlış olduğunu, veritabanını mock’layan bir test asla söyleyemez — çünkü o test, sorgunun gittiği yeri sahteyle değiştirmiştir. Veri yoğunluklu sistemlerdeki N+1 gibi bir sorgu hatası, ancak gerçek veritabanına giden bir test ile yakalanır.
Mock’u, kontrol edemediğiniz ve yavaş olan dış şeyler için saklayın — bir ödeme sağlayıcısı gibi. Kendi veritabanınızı mock’lamak, çoğu zaman testi gerçeklikten koparmaktır.
“Bütün testler yeşil” cümlesi, “production güvende” demek değildir. Hangi testin hangi hatayı engellediğini bilmiyorsanız, test sayınız bir güven kaynağı değil, bir histir.
Test bütçenizi, hataların gerçekten doğduğu yere — bileşenlerin arasına — ayırın.