Semakin banyak integrasi dalam sebuah aplikasi, semakin mudah test suite berubah menjadi sesuatu yang lambat dan merepotkan.
Database, payment gateway, API internal, message broker, sampai layanan pihak ketiga membuat satu skenario pengujian bisa bergantung pada banyak komponen sekaligus.
Di sinilah Strategi Test Pyramid membantu tim menentukan jenis pengujian yang tepat pada level yang tepat.
Tujuannya bukan sekadar memiliki banyak automated test, tetapi menciptakan kombinasi pengujian yang memberikan feedback cepat, mampu menemukan kegagalan integrasi, dan tetap mudah dipelihara ketika sistem terus bertambah besar.
Pahami Test Pyramid sebagai Panduan, Bukan Rumus Kaku
Konsep Test Pyramid pada dasarnya mendorong tim memiliki banyak pengujian kecil dan cepat di bagian bawah, lalu semakin sedikit pengujian ketika cakupannya semakin luas.
Martin Fowler menjelaskan bahwa ide utamanya adalah mempunyai jauh lebih banyak low-level unit test dibanding broad-stack test yang menjalankan sebagian besar sistem sekaligus.
Dalam praktik modern, lapisannya sering digambarkan sebagai unit test, integration test, lalu end-to-end test.
Namun jangan terlalu terikat pada nama tersebut.
Google pernah membagi pengujian berdasarkan ukuran menjadi small, medium, dan large test. Small test biasanya mirip unit test, medium mencakup beberapa komponen, sedangkan large test dapat menjalankan sistem secara lebih menyeluruh.
Yang lebih penting adalah scope, kecepatan, dependency, dan feedback yang diberikan masing-masing test.
Jadikan Unit Test sebagai Fondasi Utama
Unit test cocok untuk menguji business logic yang tidak membutuhkan database, network, atau external API sungguhan.
Misalnya aplikasi e-commerce mempunyai aturan diskon: pelanggan premium mendapatkan potongan 10% jika nilai transaksi melewati batas tertentu.
Seluruh kombinasi aturan tersebut bisa diuji melalui unit test.
Tidak perlu menjalankan database, payment gateway, atau web server hanya untuk memastikan fungsi kalkulasi diskon bekerja.
Keuntungan terbesar unit test adalah kecepatannya. Ratusan bahkan ribuan test bisa dijalankan setiap kali developer melakukan perubahan.
Google menyarankan memiliki fondasi unit test yang kuat karena pengujian jenis ini membantu menangkap bug lebih awal dan memberikan feedback sebelum kode masuk lebih jauh ke proses delivery.
Namun hindari mocking secara berlebihan.
Jika hampir setiap object dalam aplikasi harus di-mock agar sebuah test berjalan, struktur kode mungkin terlalu coupled.
Gunakan Integration Test untuk Boundary yang Benar-Benar Penting
Aplikasi yang memiliki banyak integrasi tidak bisa hanya mengandalkan unit test.
Ada perilaku yang baru terlihat ketika aplikasi benar-benar berkomunikasi dengan database, filesystem, framework, atau service lainnya.
Microsoft menjelaskan integration test sebagai pengujian yang memastikan dua atau lebih komponen bekerja bersama, termasuk infrastructure seperti database, filesystem, dan network.
Integration test juga lebih mahal daripada unit test karena membutuhkan lebih banyak proses dan dependency.
Karena itu, jangan menguji setiap kombinasi business logic melalui integration test.
Misalnya aplikasi mempunyai repository untuk menyimpan order.
Cukup pastikan operasi penting seperti menyimpan, membaca, memperbarui, dan menghapus data berjalan benar terhadap database.
Edge case seperti perhitungan diskon atau validasi nominal lebih baik tetap berada di unit test.
Dengan pendekatan ini, coverage tetap kuat tanpa membuat pipeline menjadi terlalu lambat.
Tambahkan Contract Test di antara Banyak Service
Pada proyek dengan banyak API internal, contract testing menjadi lapisan yang sangat berguna.
Bayangkan Order Service bergantung pada Customer Service.
Order mengharapkan respons:
id, name, dan membershipLevel.
Suatu hari tim Customer mengganti membershipLevel menjadi membership_type.
Secara lokal, kedua service mungkin tetap lolos unit test. Namun integrasi production bisa rusak.
Contract test membantu mendeteksi perubahan semacam ini sebelum deployment.
Pact mendefinisikan contract testing sebagai cara memeriksa apakah pesan atau request-response antara aplikasi sesuai dengan pemahaman bersama yang terdokumentasi dalam sebuah contract.
Pendekatan ini sangat berguna ketika banyak service harus saling berkomunikasi.
Contract Test Bukan Pengganti Functional Test
Contract test sebaiknya tidak digunakan untuk menguji seluruh business logic provider.
Pact menekankan bahwa fokus contract test adalah memastikan consumer dan provider mempunyai pemahaman yang sama tentang request serta response, bukan mengulang semua functional testing milik provider.
Dengan batas tersebut, test tetap kecil dan terarah.
Tim juga dapat mengurangi kebutuhan menjalankan seluruh ekosistem service hanya untuk mengecek kompatibilitas satu API.
Gunakan Test Double untuk Dependency Eksternal
Third-party API sering menjadi sumber test yang tidak stabil.
Bayangkan integration test harus menghubungi payment provider sungguhan. Test dapat gagal karena koneksi internet, rate limit, maintenance provider, atau perubahan test environment.
Padahal kode Anda sebenarnya baik-baik saja.
Untuk kondisi seperti ini, gunakan stub, fake, mock server, atau test double yang merepresentasikan dependency eksternal.
Dalam panduan practical test pyramid, penggunaan stub untuk external service membantu membuat test lebih cepat dan predictable tanpa harus menjalankan sistem pihak ketiga setiap saat.
Namun jangan hanya mengandalkan fake selamanya.
Tetap sediakan beberapa test yang memastikan asumsi Anda terhadap provider sungguhan masih benar.
Keseimbangannya penting: terlalu banyak real dependency membuat test rapuh, sementara terlalu banyak fake bisa membuat test berbeda dari kondisi production.
Batasi End-to-End Test pada Critical User Journey
Kesalahan umum dalam proyek besar adalah mencoba menguji semua hal melalui browser atau end-to-end environment.
Hasilnya biasanya test suite membutuhkan waktu puluhan menit bahkan berjam-jam.
Google menjelaskan bahwa end-to-end test cenderung lebih lambat, lebih rentan flaky, dan ketika gagal sering lebih sulit menentukan lokasi bug dibanding pengujian yang lebih kecil.
Karena itu, gunakan E2E hanya untuk alur yang benar-benar kritis.
Pada aplikasi marketplace, contohnya bisa berupa:
pengguna login → mencari produk → menambahkan ke keranjang → melakukan pembayaran → order berhasil dibuat.
Tidak perlu mengulang 50 variasi diskon melalui browser.
Variasi tersebut sudah bisa diuji jauh lebih cepat pada unit atau integration layer.
Google juga menyarankan end-to-end testing difokuskan pada Critical User Journeys, yaitu perjalanan pengguna yang mewakili tujuan terpenting produk.
Pendekatan ini menjaga test suite tetap bernilai tanpa menjadi beban maintanance.
Hindari Test yang Sama di Semua Level
Lebih banyak test tidak selalu berarti kualitas lebih tinggi.
Jika satu aturan bisnis sudah diuji secara lengkap melalui 20 unit test, mengulang semua skenario tersebut pada integration dan E2E test hanya menambah waktu eksekusi.
Martin Fowler menyarankan mendorong test sejauh mungkin ke bagian bawah pyramid selama level tersebut sudah memberikan confidence yang dibutuhkan.
Test yang lebih tinggi sebaiknya menguji perilaku yang memang tidak bisa dibuktikan oleh level di bawahnya.
Misalnya unit test membuktikan perhitungan total order benar.
Integration test membuktikan order tersimpan dengan schema yang benar.
Contract test membuktikan komunikasi antara Order dan Payment kompatibel.
E2E test kemudian cukup membuktikan bahwa pelanggan benar-benar dapat menyelesaikan checkout.
Tidak ada kebutuhan untuk mengulang seluruh edge case di setiap lapisan.
Dengan cara ini, test suite tetap cepat, mudah dipahami, dan tidak penuh duplikasi yang akhirnya sulit dirawaat.
Strategi Test Pyramid untuk proyek dengan banyak integrasi membutuhkan pembagian tanggung jawab yang jelas.
Gunakan unit test untuk logic, integration test untuk infrastructure boundary, contract test untuk komunikasi service, dan sedikit E2E test untuk perjalanan pengguna kritis.
Evaluasi test suite Anda hari ini, lalu pindahkan skenario yang terlalu mahal ke level pengujian paling rendah yang masih memberikan confidence.