Unit Test Sebagai Penjagaan #

Dalam praktik software engineering modern, pull request (PR) bukan sekadar formalitas untuk menggabungkan kode. PR adalah quality gate. Salah satu pendekatan yang terbukti sangat efektif untuk menjaga kualitas sebelum kode di-merge adalah menjadikan unit test sebagai guard di pull request.

Saya juga pernah berada di perusahaan yang menerapkan pola ini secara disiplin. Hasilnya terasa nyata: lebih sedikit bug lolos ke production, diskusi PR lebih fokus, dan engineer merasa punya safety net sebelum kode mereka digabungkan.

Artikel ini membahas dasar berpikirnya, mengapa pendekatan ini penting, dan best practice dalam menerapkannya.

Apa Itu Unit Test sebagai Guard di Pull Request? #

Unit test sebagai guard di pull request berarti:

Pull request tidak boleh di-merge jika unit test gagal atau jika perubahan kode tidak memiliki cakupan test yang memadai.

Secara praktis, ini biasanya diwujudkan dalam bentuk:

• CI pipeline yang otomatis menjalankan unit test saat PR dibuat atau di-update
• Rule di repository (GitHub/GitLab/Bitbucket) yang memblok merge jika pipeline gagal
• Standar tim bahwa perubahan logic wajib disertai unit test

Dengan kata lain, unit test berfungsi sebagai penjaga gerbang sebelum kode masuk ke branch utama.

Dasar Berpikir: Mengapa Unit Test Dijadikan Guard? #

PR Bukan Tempat Utama Menemukan Bug #

Reviewer manusia memiliki keterbatasan:

• Tidak mungkin mengeksekusi semua skenario di kepala
• Mudah melewatkan edge case
• Fokus pada gaya, struktur, dan readability

Unit test mengisi celah ini dengan cara:

• Mengeksekusi skenario secara deterministik
• Menjadi bukti bahwa kode benar-benar berjalan sesuai ekspektasi

PR seharusnya menjawab dua pertanyaan:

1. Apakah desain dan implementasinya masuk akal?
2. Apakah perubahan ini terbukti aman secara otomatis?

Unit test menjawab pertanyaan kedua.

Shift-Left Quality #

Menjadikan unit test sebagai guard adalah bentuk nyata dari shift-left testing:

• Masalah ditemukan sebelum merge
• Bukan di QA
• Bukan di staging
• Apalagi di production

Semakin ke kanan bug ditemukan, semakin mahal biayanya:

• Perbaikan
• Context switching
• Incident
• Trust user

Safety Net untuk Engineer #

Ini poin yang sering diremehkan tapi sangat penting.

Dengan unit test sebagai guard:

• Engineer berani refactor
• Engineer lebih percaya diri mengubah kode lama
• Engineer tidak takut “merusak sesuatu yang tidak terlihat”

Unit test berubah fungsi dari sekadar alat testing menjadi:

asuransi perubahan kode

Mengapa Ini Sangat Penting dalam Skala Tim? #

Mengurangi Beban Reviewer #

Tanpa unit test sebagai guard:

• Reviewer harus lebih paranoid
• Review jadi lama
• Diskusi berputar di “apakah ini aman?”

Dengan guard:

• Reviewer tahu: test sudah lewat
• Fokus ke desain, naming, dan arsitektur

Konsistensi Kualitas Kode #

Dalam tim:

• Skill engineer berbeda-beda
• Pengalaman berbeda
• Familiaritas dengan domain berbeda

Unit test sebagai guard menciptakan baseline kualitas yang objektif:

• Tidak tergantung siapa yang submit PR
• Tidak tergantung siapa yang review

Dokumentasi Perilaku Sistem yang Hidup #

Unit test yang baik adalah:

• Dokumentasi perilaku
• Contoh penggunaan
• Penjelasan implicit tentang edge case

Saat PR di-merge dengan unit test:

• Tim masa depan punya konteks
• Perubahan berikutnya lebih aman

Best Practice #

Wajibkan Unit Test untuk Perubahan Logic #

Tidak semua perubahan butuh test baru, tapi:

• Perubahan business logic → wajib
• Bug fix → wajib ada test yang gagal sebelum fix
• Refactor besar → wajib test tetap hijau

Rule sederhana:

If behavior changes, tests must change.

Jangan Jadikan Coverage sebagai Satu-satunya Metrik #

Code coverage itu indikator, bukan tujuan.

Hindari:

• Test hanya demi angka
• Assertion yang tidak bermakna
• Test yang selalu lolos tapi tidak memverifikasi apa-apa

Lebih baik:

• Coverage moderat tapi test bermakna
• Fokus pada critical path dan edge case

Test Harus Cepat #

Sebagai guard, unit test harus:

• Cepat dieksekusi
• Deterministik
• Tidak tergantung network atau external service

Jika test lambat:

• Developer tergoda untuk skip
• CI jadi bottleneck

Prinsip penting:

Guard yang lambat akan dilewati.

Pisahkan Unit Test dan Integration Test #

Untuk PR guard:

• Unit test → wajib & blocking
• Integration / E2E test → bisa non-blocking atau stage berikutnya

Ini menjaga keseimbangan antara:

• Kecepatan feedback
• Kedalaman pengujian

Jadikan Ini Budaya, Bukan Sekadar Rule #

Tool bisa memaksa, tapi budaya yang menjaga.

Budaya yang sehat:

• Reviewer berani menolak PR tanpa test
• Author tidak defensif saat diminta test
• Tim melihat test sebagai aset, bukan beban

Penutup #

Menjadikan unit test sebagai guard di pull request bukan soal tooling atau CI semata. Ini soal mindset:

• Bahwa kualitas dibangun sebelum merge
• Bahwa engineer pantas mendapatkan safety net
• Bahwa PR adalah gerbang kualitas, bukan hanya formalitas

Pengalaman bekerja di tim yang menerapkan ini dengan benar biasanya meninggalkan satu kesan kuat:

Sekali merasakan aman bekerja dengan guard ini, sulit kembali ke cara lama.

Dan itu pertanda bahwa praktik ini memang layak dijadikan standar.