Belajar Jest - Operational Readiness & Runbooks

#Pendahuluan

Suite test adalah sistem yang juga perlu dioperasikan: dia bisa sakit, flaky, dan mengalami regresi seperti halnya aplikasi produksi. Episode 19 membahas operational readiness & runbooks — dokumen prosedur yang siap pakai saat suite gagal, pengelolaan debugging dan kepemilikan test, strategi maintenance untuk skala besar, serta pemulihan dari test regressions.

Bedakan dua cara menangani masalah: reaktif, yang baru bergerak setelah masalah terjadi, dan prosedural, yang punya langkah siap pakai sejak awal. Runbook mengubah tim dari mode reaktif menjadi mode prosedural.

Tim yang tangguh tidak menghafal cara menangani kegagalan; mereka punya runbook. Episode ini mengajarkan kalian menyusunnya.

#Runbook untuk Failing Test Suites

#Prosedur Standar Diagnosis

Runbook pertama yang dibutuhkan: apa yang dilakukan saat suite gagal. Prosedur standarnya:

1. Lihat ringkasan — berapa test gagal dan di file mana.
2. Baca pesan error dan diff assertion.
3. Tentukan apakah kegagalan berasal dari kode, environment, atau test itu sendiri.
4. Perbaiki, lalu jalankan ulang suite yang terdampak.

npx jest --runInBand --silent=false 2>&1 | tee test-output.log

Perintah npx jest --runInBand --silent=false menjalankan suite serial dan menyalin semua output ke file log — artefak yang berguna untuk investigasi atau diskusi tim.

#Runbook untuk Flaky Test

Flaky test memiliki runbook tersendiri karena polanya khas: terkadang lulus, terkadang gagal. Langkahnya:

1. Jalankan suite berulang untuk mereproduksi (lihat pola loop di episode 18).
2. Catat pola: apakah gagal hanya dalam urutan tertentu atau saat paralel?
3. Cari sumber flakiness: timer, jaringan, urutan file, atau state global.
4. Isolasi dengan --runInBand; jika lulus, kemungkinan race kondisi paralel.

#Managing Test Debugging dan Team Ownership

#Debugging Terstruktur

Debug test yang gagal bukan tebak-tebakan. Mulai dari assertion yang paling spesifik, lalu persempit:

npx jest --runInBand -t "nama test yang gagal"

Perintah npx jest --runInBand -t "nama test yang gagal" menjalankan hanya test yang dicurigai dalam satu proses. Kombinasikan dengan console.log di dalam test — output muncul di terminal dan membantu memahami nilai aktual.

#Mencatat Temuan ke Runbook

Setiap kali kalian memecahkan kegagalan yang tidak biasa, catat langkah-langkahnya ke runbook tim. Temuan seperti "gagal hanya saat --maxWorkers di atas 4" atau "snapshot berubah karena timezone" adalah pengetahuan yang sangat berharga — dan akan hilang jika hanya tersimpan di kepala. Runbook yang hidup tumbuh setiap kali tim memecahkan masalah nyata.

#Kepemilikan Test yang Jelas

Setiap area test harus punya pemilik yang jelas: tim atau orang yang bertanggung jawab saat test area itu gagal. Tanpa kepemilikan, kegagalan berlarut-larut karena semua orang menganggap bukan bagiannya. Tandai kepemilikan di struktur direktori atau konvensi penamaan, dan pastikan alert dari CI menyebutkan kontak pemilik.

#Strategi Maintenance Skala Besar

#Pemisahan Jenis Test

Semakin besar suite, semakin penting memisahkan jenis test dan frekuensi menjalankannya:

• Unit test: cepat, dijalankan di setiap commit.
• Integration test: sedang, dijalankan di setiap pull request.
• E2E test: lambat, dijalankan sebelum rilis.

Dengan pemisahan ini, feedback cepat tetap terjaga sementara pengujian menyeluruh tetap berjalan sebelum produksi. Konfigurasi testMatch yang dipisah per jenis atau label project memudahkan penjadwalan ini. Pada tahap inilah project mode dan --selectProjects dari episode 17 benar-benar bersinar.

#Automatisasi Rutinitas

Jadikan pemeriksaan suite sebagai rutinitas otomatis: coverage trend di CI, deteksi flaky dengan menjalankan suite ganda di malam hari, dan laporan mingguan ke tim. Data rutin ini membuat masalah terdeteksi kecil-kecilan, bukan menumpuk jadi krisis. Mulailah dari satu metrik yang paling mudah diukur — misalnya persentase suite yang lulus dalam seminggu — lalu perluas saat prosesnya sudah berjalan mulus.

#Recovery dari Test Regressions

#Menemukan Kapan Regresi Terjadi

Saat sebuah test yang tadinya lulus mulai gagal, langkah pertama adalah menemukan kapan perubahannya. Git adalah alat utamanya:

git log --oneline -- src/kalkulator.test.js

git log --oneline -- <file> menampilkan riwayat commit file test. Periksa diff pada commit tempat test berubah — itu biasanya tempat regresi muncul. Jika perlu, gunakan git bisect untuk menemukan commit penyebab secara otomatis.

Ketika banyak test yang terdampak sekaligus, periksa pola umumnya: apakah semuanya menyentuh satu helper yang sama, satu fungsi utilitas, atau satu perubahan konfigurasi? Pola tersebut sering kali menunjuk ke satu akar penyebab yang lebih besar daripada sekadar satu file yang salah.

#Prosedur Rollback dan Perbaikan

Ketika regresi ditemukan, dua jalur penyembuhan: revert perubahan yang memecahkan, atau perbaiki ke depan. Pilih revert jika perubahannya kecil dan bisa dibatalkan; pilih perbaikan ke depan jika perubahan itu disengaja dan harus tetap ada. Setelah sembuh, dokumentasikan di runbook agar kejadian serupa ditangani lebih cepat berikutnya.

#Komunikasi Saat Suite Rusak

Kegagalan suite yang berkepanjangan menggerus kepercayaan tim, jadi komunikasikan dengan jujur. Saat suite rusak, beri tahu tim secepatnya, sebutkan area yang terdampak, dan berikan estimasi perbaikan. Jangan membungkam kegagalan dengan me-skip test atau menurunkan threshold coverage hanya untuk membuat build hijau — solusi itu menggeser masalah ke masa depan dengan harga yang mahal.

#Penutup

Episode 19 membahas kesiapan operasional: runbook untuk suite gagal dan flaky test, debugging terstruktur dengan kepemilikan test yang jelas, strategi maintenance skala besar dengan pemisahan jenis test, serta pemulihan dari regresi memakai Git.

Inti yang harus dibawa pulang:

• Runbook mengubah penanganan kegagalan menjadi prosedur, bukan tebak-tebakan.
• Flaky test ditangani dengan reproduksi, isolasi, dan perbaikan akar masalah.
• --runInBand -t "nama test" mengisolasi satu test untuk debugging.
• Setiap area test harus punya pemilik yang jelas.
• Pisahkan unit, integration, dan e2e sesuai frekuensi menjalankannya.
• Gunakan git log dan git bisect untuk menemukan sumber regresi.

Di episode 20 selanjutnya kita akan membahas use cases & testing patterns — contoh nyata untuk frontend app, API client, dan library package, pola behavior-driven testing, data-driven test dengan parameterized cases, serta best practices pengorganisasian test.