•3 dk okuma
Yazı yükleniyor...
Cuma günü öğleden sonrası. Haftanın son "commit"ini gönderdiniz. CI/CD pipeline'ı çalışmaya başladı. Kahvenizi alıp ekranın yeşile dönmesini bekliyorsunuz. Ancak bildirim kırmızı geliyor: "Test Failed".
Kalbiniz hızlanmıyor, paniklemiyorsunuz. Hatta kodu açıp hatayı incelemiyorsunuz bile. Sadece iç çekip o meşhur butona basıyorsunuz: "Re-run job."
On dakika sonra test geçiyor. Ekran yeşil. "Sadece geçici bir network hatasıydı," diyip bilgisayarı kapatıyorsunuz.
İşte o an, aslında kodunuzdaki bir hatayı değil, çok daha değerli bir şeyi; ekibinizin kaliteye olan inancını ve güvenini sessizce öldürdünüz.
Test otomasyonu dünyasında buna "Flaky Test" (Kararsız Test) diyoruz. Ancak bu teknik bir terimden ibaret değil; bu, mühendislik kültürünü içeriden çürüten psikolojik bir süreç.
1. Yeşil Işık İllüzyonu ve Belirsizlik
Yazılım mühendisliğinde determinizm esastır. Girdiler aynıysa, çıktılar da aynı olmalıdır. Ancak flaky testler bu kuralı ihlal eder. Bir test %1 ihtimalle bile sebepsiz yere başarısız oluyorsa, o test artık bir "doğrulama aracı" değildir. O artık bir yazı tura oyunudur.
Mühendisler bir araca (test setine) güvenmeyi bıraktığında, o araç ne kadar gelişmiş olursa olsun işlevsizleşir. Tıpkı sürekli yanlış alarm veren bir yangın alarmı gibi. Bir süre sonra sirenleri duymazdan gelmeye başlarsınız. Yazılımda buna "Alarm Yorgunluğu" (Alert Fatigue) diyoruz.
2. Sapmanın Normalleşmesi (Normalization of Deviance)
Sosyolog Diane Vaughan, Challenger uzay mekiği felaketini incelerken "Sapmanın Normalleşmesi" kavramını ortaya atmıştı. Teknik ekipler, bir sorunu (örneğin sızdıran bir contayı) yeterince uzun süre, felaketle sonuçlanmadan gözlemlerse, bu sorunu artık bir "hata" olarak değil, "sistemin normal bir parçası" olarak kabul etmeye başlarlar.
Yazılım ekiplerinde olan tam olarak budur. "O login testi bazen fail veriyor, retry et geçer." cümlesi bir ekipte normalleştiği an, kalite standardınız artık o "bazen fail veren" testin seviyesine inmiş demektir. Çünkü bir gün o test gerçekten kritik bir hatadan dolayı başarısız olduğunda, kimse dönüp bakmayacak. Herkes yine "retry" tuşuna basacak ve belki de production'a canlı bir bug göndereceksiniz.
3. Kırık Camlar Teorisi
Flaky testler, kod tabanındaki "kırık camlardır". Kriminolojik teoriye göre; bir binanın bir camı kırıksa ve tamir edilmiyorsa, yoldan geçenler diğer camları da kırmakta beis görmezler.
Test raporlarınızda sürekli birkaç "kırmızı" veya "sarı" görmeye alışkınsanız, yeni yazdığınız kodun %100 sağlam olmamasına da tolerans göstermeye başlarsınız. "Zaten build hiçbir zaman tam yeşil olmuyor ki" düşüncesi, mükemmeliyetçiliği öldürür. Disiplin bir kere gevşediğinde, teknik borç bir çığ gibi büyür.
4. Çözüm: Sıfır Tolerans
Peki çözüm ne? Daha iyi wait komutları yazmak mı? Daha güçlü sunucular mı? Hayır, çözüm felsefi bir duruş değişikliğinde.
Google ve Netflix gibi mühendislik devlerinin bu konudaki yaklaşımı radikaldir: Güven vermeyen test, hiç test olmamasından daha kötüdür.
Eğer bir test flaky ise ve hemen düzeltilemiyorsa, o testi karantinaya alın veya silin. Kulağa korkutucu geliyor değil mi? Testi silmek, coverage oranını düşürür. Ancak yanlış bilgi veren, ekibin vaktini çalan ve güveni zedeleyen bir testin yarattığı illüzyondansa, coverage'ın düşmesi daha dürüst bir yaklaşımdır.
Sonuç: Kodunuzu Değil, Güveninizi Onarın
Test otomasyonu, sadece bug yakalamak için yapılmaz. Otomasyon, geliştiricinin arkasını yaslayıp "Evet, bu değişiklik güvenli, eminim" diyebilmesi için yapılır.
Eğer testlerinizden biri bile size "Acaba?" dedirtiyorsa, o test görevini yapmıyor demektir. Kararsız testlerle savaşmak, sadece kod kalitesini değil, ekibinizin akıl sağlığını ve birbirine olan güvenini korumak için verdiğiniz bir savaştır.
Bir dahaki sefere CI pipeline'ı kırmızı yandığında "tekrar dene" butonuna basmadan önce durun ve düşünün: Şu an sadece bir testi mi geçiştiriyorum, yoksa mühendislik kültürümüzden bir parça daha mı koparıyorum?