Di Mana Setiap Tes Harus Dijalankan dalam Pipeline Anda?

Anda push kode dan menunggu. Lima menit berlalu. Sepuluh menit. Pipeline masih berjalan. Akhirnya gagal — tetapi errornya berasal dari unit test yang seharusnya berjalan dalam tiga puluh detik pertama. Anda baru saja membuang sepuluh menit waktu dan sumber daya komputasi.

Inilah ketegangan inti dalam desain pipeline: jika terlalu banyak tes dijalankan di awal, developer menunggu terlalu lama untuk mendapatkan feedback. Jika terlalu sedikit, kegagalan kritis lolos ke staging atau produksi. Solusinya bukan menjalankan semuanya di mana-mana, tetapi menempatkan setiap jenis tes pada stage yang memberikan nilai paling besar dengan biaya paling rendah.

Prinsip: Cepat dan Murah Dulu

Aturannya sederhana: jalankan tes yang cepat dan murah terlebih dahulu. Jalankan tes yang lambat dan mahal belakangan, dan hanya setelah tes sebelumnya lolos.

"Murah" di sini berarti rendah dalam waktu komputasi, penyiapan lingkungan, dan persiapan data. Unit test yang berjalan dalam milidetik dan tidak membutuhkan database adalah murah. End-to-end test yang memutar lingkungan lengkap, menyemaikan data, dan mensimulasikan perjalanan pengguna adalah mahal.

"Cepat" berarti loop feedback. Seorang developer harus tahu dalam satu atau dua menit apakah perubahan mereka merusak sesuatu yang fundamental. Menunggu tiga puluh menit untuk menemukan kesalahan logika dasar tidak dapat diterima.

Ini bukan tentang kebijakan. Ini tentang throughput. Semakin cepat developer mendapatkan feedback, semakin cepat mereka memperbaiki masalah. Semakin mahal biaya menjalankan sebuah tes, semakin jarang tes itu harus dijalankan.

Stage demi Stage: Di Mana Tes Berada

Commit Stage: Unit Test dan Contract Test

Diagram alir berikut merangkum penempatan tes yang direkomendasikan di seluruh stage pipeline:

flowchart TD A[Commit Stage] --> B[Build Stage] B --> C[Staging Stage] C --> D[Production Stage] A --> A1[Unit Tests] A --> A2[Contract Tests] B --> B1[Integration Tests] B --> B2[Contract Tests] C --> C1[End-to-End Tests] C --> C2[Smoke Tests] D --> D1[Smoke Tests] D --> D2[Synthetic Transactions]

Ketika seorang developer push kode, hal pertama yang dijalankan adalah unit test. Tes-tes ini cepat, tidak membutuhkan dependensi eksternal, dan memverifikasi bahwa perilaku individual berfungsi dengan benar. Unit test yang baik membuktikan bahwa perilaku yang bermakna — dari sudut pandang pemanggil atau pengguna — menghasilkan hasil yang diharapkan. Tes ini tidak peduli dengan detail implementasi internal.

Beberapa tim juga menjalankan contract test pada stage ini. Jika perubahan menyentuh antarmuka atau kontrak API, memverifikasinya sejak awal mencegah kejutan di hilir. Contract test biasanya cukup cepat untuk dijalankan bersamaan dengan unit test.

Apa yang tidak boleh dijalankan di sini: integration test, end-to-end test, atau tes apa pun yang membutuhkan database, layanan eksternal, atau lingkungan lengkap. Semua itu ada di stage berikutnya.

Build Stage: Integration Test dan Contract Test Lagi

Setelah kode dikompilasi dan menghasilkan artefak atau image container, integration test mulai berperan. Pada stage ini, aplikasi sudah ada sebagai unit yang dapat dijalankan. Integration test memeriksa bahwa aplikasi terhubung dengan benar ke dependensinya — database, message queue, atau layanan lainnya.

Tes-tes ini biasanya menggunakan test double atau container ringan, bukan lingkungan staging penuh. Mereka memverifikasi bahwa wiring sudah benar: aplikasi dapat membuka koneksi, mengirim query, dan menangani respons.

Contract test sering dijalankan lagi di sini, terhadap artefak yang sudah dibangun. Ini memastikan bahwa kode yang dikompilasi masih memenuhi kontrak, bukan hanya kode sumber.

Staging Stage: End-to-End Test dan Smoke Test

Staging harus mencerminkan produksi semirip mungkin. Di sinilah Anda menjalankan end-to-end test — tetapi hanya untuk perjalanan kritis pengguna. Bukan setiap halaman, bukan setiap fitur. Hanya alur yang paling penting: login, checkout, pencarian, atau apa pun logika bisnis inti Anda.

End-to-end test lambat dan mahal. Menjalankannya untuk setiap perubahan kecil hanya membuang waktu. Cadangkan untuk perubahan yang menyentuh jalur kritis atau memperkenalkan fungsionalitas baru.

Smoke test juga dijalankan di sini. Smoke test adalah pemeriksaan cepat bahwa aplikasi merespons dengan benar setelah deployment. Jika smoke test gagal di staging, jangan lanjutkan ke produksi. Hentikan pipeline dan selidiki.

Production Stage: Smoke Test dan Synthetic Transaction

Di produksi, tes harus minimal dan tidak boleh memengaruhi pengguna. Jalankan smoke test segera setelah deployment untuk memastikan bahwa endpoint utama merespons dengan kode status yang benar. Ini bukan validasi mendalam — hanya sanity check bahwa deployment tidak merusak aplikasi.

Synthetic transaction berjalan secara periodik, bukan tepat setelah setiap deployment. Mereka mensimulasikan interaksi pengguna — seperti login atau menyelesaikan pembelian — untuk mendeteksi regresi yang tidak tertangkap di staging. Karena berjalan sesuai jadwal, mereka menangkap masalah yang muncul seiring waktu, seperti kebocoran memori atau korupsi data.

Apa yang Tidak Boleh Dilakukan

Jangan menjalankan semua tes di semua stage. Ini adalah kesalahan paling umum. Menjalankan end-to-end test di commit stage tidak masuk akal — lingkungan belum siap, dan feedback terlalu lambat. Menjalankan unit test lagi di production stage adalah pemborosan — logika tidak berubah antara staging dan produksi.

Aturan praktis yang baik: jika sebuah tes lolos di stage sebelumnya, jangan ulangi di stage berikutnya kecuali perubahan lingkungan dapat memengaruhi hasil. Unit test tidak bergantung pada lingkungan, jadi tidak perlu dijalankan lagi. Smoke test bergantung pada deployment, jadi harus dijalankan di setiap lingkungan baru.

Risk-Based Testing dalam Pipeline

Penempatan tes juga tergantung pada risiko. Perubahan pada sistem pembayaran atau logika autentikasi memerlukan lebih banyak lapisan pengujian. Perubahan pada warna tombol atau typo di label hanya membutuhkan unit test dan smoke test.

Ini adalah risk-based testing yang diterapkan pada pipeline: semakin tinggi risiko perubahan, semakin banyak lapisan tes yang harus dilalui. Semakin rendah risiko, semakin cepat perubahan dapat bergerak melalui pipeline.

Beberapa tim menerapkan ini dengan menandai perubahan atau menggunakan kebijakan branch. Jalur kritis memerlukan end-to-end test di staging. Jalur non-kritis melewatinya. Ini menjaga pipeline tetap cepat untuk perubahan berisiko rendah sambil mempertahankan keamanan untuk perubahan berisiko tinggi.

Daftar Periksa Praktis untuk Penempatan Tes

  • Unit test berjalan di commit stage. Cepat, tanpa dependensi, feedback instan.
  • Contract test berjalan di commit dan build stage. Verifikasi antarmuka sejak awal dan terhadap artefak.
  • Integration test berjalan di build stage. Periksa koneksi ke dependensi menggunakan container atau test double.
  • End-to-end test berjalan hanya di staging stage. Mencakup perjalanan kritis pengguna, bukan setiap fitur.
  • Smoke test berjalan di staging dan production stage. Pemeriksaan sanity cepat setelah setiap deployment.
  • Synthetic transaction berjalan secara periodik di produksi. Menangkap regresi seiring waktu.
  • Jangan ulangi tes di seluruh stage kecuali perubahan lingkungan memang penting.
  • Sesuaikan lapisan tes berdasarkan risiko. Perubahan berisiko tinggi mendapatkan cakupan lebih banyak.

Kesimpulan

Tes yang ditempatkan dengan baik memberi Anda feedback cepat saat dibutuhkan dan validasi menyeluruh saat Anda mampu. Tujuannya bukan menguji semuanya di mana-mana. Tujuannya adalah menangkap kegagalan yang tepat pada waktu yang tepat, sehingga tim Anda dapat memperbaikinya sebelum mencapai produksi.