End-to-End Test: Kapan Membantu dan Kapan Hanya Memperlambat

Kamu sudah punya unit test yang memeriksa setiap fungsi. Integration test yang memverifikasi query database. Contract test yang memastikan kesepakatan API tetap terjaga. Pipeline hijau. Semua terlihat baik-baik saja.

Lalu kamu deploy, dan seorang pengguna melaporkan bahwa mereka bisa login, mencari produk, menambahkannya ke keranjang, tapi tombol checkout tidak melakukan apa-apa. Tidak ada error. Tidak ada crash. Hanya diam.

Setiap komponen bekerja sendiri-sendiri. Bersama-sama, mereka gagal.

Inilah celah yang ingin ditutup oleh end-to-end test. Tapi menutup celah itu punya biaya yang bisa merusak kecepatan pipeline dan moral tim jika kamu tidak hati-hati.

Apa yang Sebenarnya Dilakukan End-to-End Test

End-to-end test menjalankan seluruh sistem kamu seperti yang dilakukan pengguna sungguhan. Aplikasi berjalan. Database berisi data nyata. API eksternal dipanggil secara nyata. Browser atau klien mobile melakukan interaksi aktual.

Bayangkan alur pembelian lengkap: login, cari produk, tambah ke keranjang, masukkan detail pembayaran, konfirmasi pesanan, lihat struk. Tidak ada yang di-mock. Tidak ada yang diganti dengan test double. Setiap bagian sistem berpartisipasi.

Keyakinan dari end-to-end test yang lolos itu nyata. Jika alur kritis kamu lolos, kamu bisa cukup yakin bahwa pengguna tidak akan menemui jalan buntu di fitur utama. Tapi keyakinan itu mahal.

Biaya Sebenarnya dari End-to-End Test

Satu end-to-end test bisa memakan waktu beberapa menit. Kalikan dengan puluhan skenario, dan kamu akan melihat waktu pipeline berjam-jam. Dan itu saat semuanya berjalan lancar.

End-to-end test gagal karena alasan yang tidak ada hubungannya dengan kode kamu. Timeout karena lingkungan test lambat. Data test tidak konsisten sisa dari eksekusi sebelumnya. Koneksi database habis karena test paralel. API eksternal membatasi permintaan test kamu.

Ketika test gagal secara acak, tim berhenti mempercayai pipeline. Developer mulai mengklik "retry" tanpa menyelidiki. Test suite menjadi noise, bukan sinyal.

Inilah mengapa kamu tidak bisa membuang end-to-end test ke semua hal. Kamu harus bedah secara surgical tentang apa yang kamu test dan bagaimana menjalankannya.

Kapan End-to-End Test Benar-Benar Diperlukan

End-to-end test diperlukan ketika sebuah skenario tidak bisa diverifikasi oleh jenis test lain. Ini biasanya berarti alur yang melintasi banyak komponen dalam satu perjalanan pengguna.

Alur pembayaran adalah contoh klasik. Unit test bisa memverifikasi logika kalkulasi harga. Integration test bisa memeriksa bahwa pesanan tersimpan ke database. Contract test bisa mengonfirmasi format request ke payment gateway. Tapi tidak satu pun dari ini bisa membuktikan bahwa pengguna sungguhan benar-benar bisa menyelesaikan pembelian dari awal hingga akhir. Hanya end-to-end test yang bisa melakukannya.

Kriteria lain adalah risiko. Jika sebuah fitur rusak akan menyebabkan kerusakan signifikan, itu layak mendapatkan end-to-end test. Login adalah kandidat bagus karena jika rusak, tidak ada yang bisa menggunakan aplikasi. Checkout adalah kandidat lain karena langsung memengaruhi pendapatan.

Di sisi lain, halaman profil pengguna yang jarang berubah, atau fitur admin yang digunakan oleh tiga orang internal, mungkin bisa dicakup oleh integration test. Risikonya rendah, dan biaya end-to-end test tidak sebanding.

Cara Menjalankan End-to-End Test Tanpa Memperlambat Semua Orang

Setelah kamu mengidentifikasi skenario yang benar-benar membutuhkan cakupan end-to-end, tantangan berikutnya adalah menjalankannya di pipeline tanpa membuat developer menunggu selamanya.

Batasi pada perjalanan pengguna kritis. Identifikasi alur paling penting yang harus didukung aplikasi kamu agar pengguna mendapatkan nilai. Untuk situs e-commerce, itu mungkin pencarian, detail produk, tambah ke keranjang, checkout, dan pembayaran. Untuk aplikasi pesan, itu mungkin login, kirim pesan, terima pesan, dan logout. Sisanya diuji dengan metode yang lebih cepat dan murah.

Jalankan test secara paralel. Jika kamu punya sepuluh test yang masing-masing memakan waktu tiga menit, menjalankannya satu per satu menambah tiga puluh menit ke pipeline. Menjalankannya secara paralel bisa menurunkannya menjadi tiga menit, asalkan kamu memiliki infrastruktur yang cukup untuk mendukung lingkungan konkuren. Ini adalah investasi yang layak dilakukan.

Pisahkan end-to-end test ke dalam tahap pipeline sendiri. Jangan campur dengan unit test atau integration test. Biarkan test cepat berjalan lebih dulu dan memberikan feedback cepat ke developer. Hanya jalankan end-to-end test lambat setelah semuanya lolos. Dengan cara ini, developer tahu dalam beberapa menit jika unit test gagal, tanpa menunggu suite end-to-end.

Jalankan subset pada setiap commit, suite penuh secara periodik. Kamu tidak perlu menjalankan setiap end-to-end test pada setiap perubahan kode. Jalankan yang paling kritis pada setiap commit. Jalankan set lengkap setiap malam atau sebelum rilis produksi. Ini menyeimbangkan kecepatan dengan cakupan.

Berikut adalah contoh konfigurasi pipeline YAML yang menjalankan end-to-end test hanya pada jadwal malam atau saat dipicu manual, menjaga pipeline commit utama tetap cepat:

# azure-pipelines-e2e.yml
# Pipeline terpisah untuk end-to-end test

trigger: none  # Jangan jalankan pada setiap commit

schedules:
- cron: '0 2 * * *'  # Jalankan setiap malam jam 2 pagi
  displayName: End-to-end test malam hari
  branches:
    include:
    - main

resources:
  pipelines:
  - pipeline: mainBuild
    source: main-ci
    trigger:
      branches:
        include:
        - main

jobs:
- job: e2e_tests
  displayName: 'Jalankan End-to-End Test'
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: |
      echo "Memulai suite end-to-end test..."
      npm run test:e2e
    displayName: 'Eksekusi test E2E'

Buat test tangguh terhadap lingkungan yang tidak stabil. Gunakan percobaan ulang untuk kegagalan yang disebabkan oleh timeout. Reset data test ke keadaan yang diketahui sebelum setiap test dijalankan. Jika sebuah test sering gagal karena alasan teknis, perbaiki test atau lingkungannya. Jangan biarkan test yang tidak stabil mengikis kepercayaan pada pipeline.

Daftar Periksa Praktis

Sebelum menambahkan end-to-end test baru, tanyakan pertanyaan-pertanyaan ini:

• Bisakah skenario ini diverifikasi oleh jenis test yang lebih cepat?
• Jika alur ini rusak, berapa banyak pengguna yang terkena dampak dan seberapa parah?
• Apakah ini perjalanan pengguna kritis atau alur yang nice-to-have?
• Bisakah kita menjalankan test ini secara paralel dengan yang lain?
• Apakah test ini tangguh terhadap masalah lingkungan?

Jika jawaban untuk pertanyaan pertama adalah ya, jangan tulis end-to-end test. Jika risikonya rendah, jangan tulis. Jika bukan perjalanan kritis, jangan tulis.

Kesimpulan

End-to-end test memberi kamu keyakinan tertinggi bahwa sistem kamu bekerja secara keseluruhan. Tapi keyakinan itu mahal dalam waktu, infrastruktur, dan pemeliharaan. Gunakan hanya untuk alur yang paling penting. Jalankan dengan cerdas sehingga mereka tidak menjadi bottleneck yang membuat tim kamu takut dengan pipeline.

Beberapa end-to-end test yang dipilih dengan baik dan berjalan andal lebih berharga daripada seratus test tidak stabil yang tidak dipercaya siapa pun.