Mesin Status Moderasi Ulasan: Validasi Transisi State Melalui Pengujian Integrasi
Uji integrasi membuktikan mesin status moderasi: seed agregat salah 9.9/999, Remove mengisi audit, Restore membersihkannya, agregat dihitung ulang dua arah.
Ringkasan
Jadi sistem review ini punya mesin status: hapus review langsung ganti status jadi dihapus plus isi kolom audit, bukan cuma nunggu proses belakang. Batasannya ketat banget, alasan hapus cuma enam pilihan, rating harus 1-5, komentar maksimal 2000 karakter. Semua transisi diuji pakai table-driven test, makanya perilakunya dijamin konsisten, bukan sekadar asumsi.
Mesin Status Moderasi Ulasan: Validasi Transisi State Melalui Pengujian Integrasi
Saat menjalankan pengujian integrasi, sistem sengaja menyuntikkan agregat data yang salah secara ekstrem, seperti avg_rating 9,9 dan review_count 999. Ketika fungsi Remove dipanggil sekali, nilai agregat tersebut langsung tertimpa oleh jalur rekalkulasi produksi. Hal ini membuktikan bahwa rekalkulasi agregat berjalan secara nyata melalui logika produksi, bukan sekadar pembaruan manual yang disisipkan khusus untuk pengujian [1].
Dugaan awal menganggap bahwa penghapusan ulasan hanya mengubah kolom status menjadi dihapus dan membiarkan agregat tetap utuh hingga ada proses latar belakang yang memperbaruinya. Asumsi ini juga mengira bahwa kolom audit diisi secara opsional atau manual oleh pengembang saat proses debugging.
Kenyataannya, alur Remove(id, reason, note, actor) secara atomis memindahkan status dari disetujui menjadi dihapus. Proses ini secara wajib mengisi empat kolom audit: removal_reason, removal_note, removed_by, dan removed_at. Alasan penghapusan dibatasi ketat pada enam nilai daftar putih (spam_promosi, judi_online, sara_kebencian, hoaks, data_pribadi, lainnya) dengan spasi di sekitarnya yang otomatis dipangkas. Catatan opsional dibatasi maksimal 1000 karakter (1001 karakter ditolak) dan juga dipangkas.
Panggilan Remove kedua pada baris yang sudah dihapus akan mengembalikan ErrNotFound. Hal ini terjadi karena klausa UPDATE WHERE secara eksplisit mengecualikan status yang sudah dihapus, menghasilkan RowsAffected bernilai nol. Sebaliknya, operasi pemulihan membalikkan status kembali ke disetujui, sekaligus mengosongkan keempat kolom audit tersebut menjadi NULL kembali. Agregat juga dihitung ulang di kedua arah: setelah penghapusan rata-rata menjadi 2 dengan jumlah 1, dan setelah pemulihan rata-rata menjadi 3 dengan jumlah 2. Ulasan berstatus tertunda atau ditolak juga dapat dihapus melalui mekanisme yang sama.
Kontrak pembuatan ulasan dirancang dengan batasan yang presisi. Batas peringkat 1 dan 5 diterima, sedangkan 0 dan 6 memicu ErrInvalidRating tanpa memengaruhi baris data. Panjang komentar dihitung dalam satuan rune, sehingga 2000 karakter multibyte diterima, tetapi 2001 karakter ditolak. Komentar, alamat IP, atau agen pengguna yang kosong disimpan sebagai NULL dalam SQL. Duplikasi berdasarkan user_id dan entity_id diblokir di tingkat layanan dan repositori, tempat kesalahan MySQL 1062 diterjemahkan menjadi ErrAlreadyReviewed.
Penanda Karakterisasi dalam Transisi State
Pengujian karakterisasi mencatat perilaku sistem yang spesifik tanpa memberikan penilaian moral [2]. Ulasan yang telah dihapus tetap mengunci pengguna tersebut agar tidak dapat mengulas entitas yang sama, dengan penanda status 'owner decision pending'. Endpoint POST /reviews mengembalikan kode 201 dengan status tubuh 'pending', meskipun baris yang tersimpan berstatus 'approved' untuk penerbitan instan. Pada antarmuka administrasi, ID non-numerik menghasilkan respons 404 karena ParseInt jatuh ke nilai 0, sedangkan ID entitas yang buruk pada API publik menghasilkan respons 400.
Rekalkulasi Statistik dan Ketahanan Router
Perhitungan statistik membulatkan rata-rata ke satu desimal menggunakan rumus math.Round(x*10)/10, sehingga 4,25 menjadi 4,3, 4,24 menjadi 4,2, dan 2,95 menjadi 3,0. Paginasi menerapkan penjepitan nilai: halaman kurang dari 1 menjadi 1, batas 0 menjadi 10, dan 51 menjadi 10. Pengujian penangan menggerakkan router chi yang nyata melalui httptest [3]. Ketika basis data ditutup, setiap titik akhir administrasi secara konsisten mengembalikan kode 500, memastikan tidak ada kegagalan diam-diam.
Transisi State Sebagai Kontrak
Pendekatan pengujian berbasis tabel memverifikasi setiap transisi state secara terisolasi [4]. Dengan memvalidasi setiap kondisi batas dan efek samping, mesin status moderasi ulasan tidak lagi bergantung pada asumsi. Pengujian per transisi mengubah jejak audit dari sekadar niat desain menjadi kontrak perangkat lunak yang terjamin [5].