Gambar 1. Pengembangan perangkat lunak (sumber: https://www.pexels.com/)

Dalam pengembangan perangkat lunak tradisional, piramida testing biasanya hanya berfokus pada tiga lapisan: Unit Test, Integration Test, dan End-to-End (E2E) Test. Namun, seiring dengan pergeseran arsitektur menuju microservices dan cloud-native, kompleksitas sistem meningkat drastis. Sebuah fitur kini bisa melibatkan belasan service yang saling berkomunikasi. Untuk memastikan keandalan sistem (reliability) dalam arsitektur terdistribusi, pendekatan testing modern telah berevolusi. Tiga pilar penting yang kini mendominasi siklus pengembangan modern adalah Unit Test, Contract Test, dan Chaos Testing.

1.    Unit Test: Fondasi Keandalan Kode

Unit test adalah pengujian pada tingkat paling rendah, di mana komponen atau fungsi individu dari perangkat lunak diuji secara terisolasi. Dalam testing modern, unit test harus berjalan sangat cepat (dalam hitungan milidetik) dan tidak memiliki dependensi eksternal (seperti database atau network).

Kapan Digunakan: Setiap kali developer menulis atau mengubah kode bisnis (business logic). Ini adalah garis pertahanan pertama sebelum kode dikirim (push) ke repository.

2.    Contract Test: Mengamankan Integrasi Antar-Service

Dalam microservices, pengujian End-to-End (E2E) konvensional seringkali menjadi bottleneck karena lambat, rapuh (flaky), dan mahal untuk dijalankan. Contract testing hadir sebagai solusi. Pengujian ini memastikan bahwa dua service terpisah (sebagai Consumer dan Provider) sepakat pada format pertukaran data (API payload). Jika salah satu service mengubah struktur datanya, contract test akan langsung gagal. Tool yang paling populer untuk ini adalah Pact.

Kapan Digunakan: Digunakan ketika beberapa microservices dikembangkan oleh tim yang berbeda, dan kita perlu memastikan perubahan pada satu service tidak merusak service lainnya tanpa harus melakukan deployment seluruh sistem.

3.    Chaos Testing (Chaos Engineering): Menguji Ketahanan Sistem

Di dunia nyata, kegagalan pasti terjadi (hardware rusak, network latency, atau matikan listrik). Chaos testing adalah praktik dengan sengaja menyuntikkan kegagalan (anomali) ke dalam sistem untuk mengamati bagaimana sistem tersebut bertahan dan pulih. Konsep ini dipopulerkan oleh Netflix dengan Chaos Monkey.

Kapan Digunakan: Digunakan pada fase prapeluncuran (staging) atau bahkan di production (bagi tim dengan maturitas tinggi) untuk memastikan fitur toleransi kesalahan (fault-tolerance), auto-scaling, dan sistem peringatan (alerting) berfungsi saat krisis.

Contoh Workflow CI/CD Pipeline Modern

Bagaimana ketiga jenis pengujian ini hidup berdampingan dalam satu siklus pengiriman otomatis? Berikut adalah ilustrasi Continuous Integration (CI) yang ideal:

Table 1. Contoh testing pada workflow CI/CD

Tahapan (Stage) Aksi yang Terjadi Durasi Ekspektasi Keputusan (Gate)
Local / Commit Developer menjalankan Unit Test dan Linter secara local. < 1 menit Gagal -> Kode tidak bisa di-commit.
CI Build Kode di-push. CI server (misal: GitHub Actions) menjalankan compile dan seluruh Unit Test aplikasi. 1 – 3 menit Gagal -> Pull Request diblokir.
Contract Verification Menjalankan Contract Test. Mengecek apakah API Endpoint baru melanggar kontrak dengan service lain (Consumer Driven Contracts). 2 – 5 menit Gagal -> Tim harus mendiskusikan perubahan API.
Deploy to Staging Kode berhasil di-build menjadi Container (Docker) dan di-deploy ke lingkungan Staging. 3 – 5 menit Lanjut ke tahap pengujian sistem.
Chaos & Resiliency Test Di Staging, sistem otomatis menjalankan script Chaos Testing (misal: mematikan 1 database node atau menunda respon API 2 detik). 10 – 20 menit Gagal -> Alerting diperbaiki / Fallback diimplementasi ulang.
Release to Production Jika semua lolos, sistem siap di-deploy (misal menggunakan strategi Canary Release atau Blue-Green Deployment). – Sukses.

 

Modern testing menuntut keseimbangan. Unit test memastikan kebenaran logika di tingkat mikro, Contract test menjamin komunikasi yang aman antar-layanan tanpa beban E2E yang berat, dan Chaos testing membuktikan ketangguhan arsitektur saat menghadapi insiden nyata. Ketiganya merupakan fondasi penting dalam mendesain sistem berskala besar.

 

Referensi

  • https://martinfowler.com/articles/practical-test-pyramid.html
  • https://docs.pact.io/