Membangun test impact analysis di pipeline CI/CD membantu mencegah regression dengan mengeksekusi hanya tes yang relevan terhadap perubahan kode. Langkah yang benar memastikan jalur regression-critical tetap terlindungi, tanpa membebani pipeline dengan seluruh suite. Artikel ini membahas pendekatan praktis untuk mengidentifikasi jalur kritis, memilih subset tes berbasis perubahan, serta mengatasi flaky test agar verifikasi tetap dapat diandalkan.

Mengapa Test Impact Analysis Penting di Pipeline

Test impact analysis memberikan keseimbangan antara cakupan regresi dan waktu eksekusi pipeline. Alih-alih menjalankan ribuan tes setiap kali commit, pipeline cukup mengeksekusi tes yang menyentuh modul terkait. Dengan begitu, regression-critical path tetap diawasi, sementara tim bisa mendapatkan umpan balik cepat untuk perubahan kecil.

Untuk menjaga efektivitas, pendekatan ini harus terus dibandingkan dengan metrik seperti durasi total tes, tingkat kegagalan historis, serta sejauh mana perubahan menyentuh area berisiko tinggi. Tanpa pendekatan yang sistematis, subset tes bisa melewatkan regresi penting.

Identifikasi Jalur Regression-Critical

Langkah pertama adalah menentukan bagian sistem yang wajib diuji setiap kali berubah. Pada proyek monolitik, ini bisa berupa service utama atau API yang sering digunakan. Di arsitektur mikro, fokus bisa pada contract antara layanan.

Gunakan data telemetri dari produksi dan riwayat bug untuk memprioritaskan. Alur praktis:

  1. Kelompokkan file/kode berdasarkan domain atau paket.
  2. Lampirkan label regression-critical pada modul dengan dampak tinggi.
  3. Tetapkan tes minimum (smoke atau sanity) yang berjalan jika modul tersebut berubah.

Hasilnya, pipeline bisa selalu menjalankan tes sanity untuk area kritis tanpa menunggu perubahan besar. Sebutlah, ketika konfigurasi API gateway berubah, jalankan sanity test Gateway, plus subset contract test.

Memicu Subset Test Berdasarkan Perubahan Kode

Untuk mengeksekusi subset tes, pertama-tama identifikasi file yang diubah. Skenario umum menggunakan git diff terhadap basis branch, lalu memetakan file ke test suite.

$ git fetch origin main
$ git diff --name-only origin/main...HEAD

Berikut pendekatan sederhana untuk menentukan tes yang dijalankan:

  • Buat mapping antara path-source dan test suite, misalnya src/api/ → tests/api/**.
  • Gunakan script untuk membaca file yang diubah, lalu cari mapping dan build daftar tes unik.
  • Jalankan tes yang teridentifikasi plus sanity test untuk jalur regression-critical.

Contoh snippet (Python) untuk mapping:

import subprocess
import json

changed_files = subprocess.run(
    ['git', 'diff', '--name-only', 'origin/main...HEAD'],
    capture_output=True, text=True
).stdout.splitlines()

mappings = {
    'src/api/': ['tests/api'],
    'src/auth/': ['tests/auth', 'tests/security'],
}

tests_to_run = set()
for path in changed_files:
    for prefix, suites in mappings.items():
        if path.startswith(prefix):
            tests_to_run.update(suites)

if tests_to_run:
    print('Menjalankan tes:', tests_to_run)
else:
    print('Hanya menjalankan smoke test')

Integrasikan skrip ini di job pipeline sebelum `test` stage untuk memilih tes sesuai perubahan. Sistem lebih kompleks bisa memanfaatkan dependency graph (misalnya tool seperti Bazel, Nx, atau gradle dengan platform-specific plugin) agar pemetaan lebih akurat.

Menangani Flaky Test untuk Verifikasi yang Andal

Flaky test merusak kepercayaan terhadap pipeline. Setelah subset tes dipilih, pastikan mekanisme deteksi dan mitigasi flaky test disiapkan:

  • Re-run terbatas: Jalankan ulang tes yang gagal sekali sebelum dianggap gagal total. Catat pola kegagalan untuk analisis.
  • Stabilitas historis: Simpan metrik rerun rate per tes. Tes dengan rerun rate tinggi perlu investigasi atau sementara dihapus dari subset seleksi.
  • Isolation dan mocking: Pastikan tes tidak bergantung pada sumber daya eksternal yang tidak deterministik.

Integrasikan data flaky ke dalam pemetaan: jika tes tertentu bermasalah, pipeline bisa otomatis menambah kandidat pengganti atau memaksa versi smoke test yang lebih sederhana.

Metrik, Tools, dan Integrasi dengan Smoke/Sanity Test

Untuk mengevaluasi efektivitas, gunakan metrik berikut:

  • Test Execution Coverage: Persentase file tersentuh yang benar-benar dieksekusi tes terkait.
  • Mean Time to Detect Regression: Waktu dari commit hingga detected failure dalam subset tes.
  • Flake Rate: Persentase rerun per 1.000 tes.

Tool yang umum: Git untuk diff, Nx/Bazel untuk dependency graph, dan CI runner (GitHub Actions, GitLab CI, Azure DevOps) untuk orchestration. Export metric ke dashboard (Grafana, DataDog) agar tim dapat memantau tren.

Strategi ini juga bersinergi dengan smoke atau sanity test sebelum release. Smoke test tetap dijalankan secara konsisten untuk area regression-critical, sementara test impact analysis melengkapi dengan subset spesifik perubahan. Jika commit menyentuh modul baru, maka pipeline bisa menggabungkan kedua pendekatan: jalankan smoke suite, lalu subset tes spesifik untuk modul terkait. Hal ini menjaga release readiness sekaligus meminimalkan biaya waktu.

Kapan Menggunakan Pendekatan Ini

Test impact analysis paling berguna saat:

  • Suite tes besar dan memakan waktu lebih dari beberapa menit.
  • Tim membutuhkan umpan balik cepat dari pipeline.
  • Ada area sistem yang membutuhkan perlindungan ekstra (pagination API, billing, security).

Namun, pendekatan ini memerlukan pengelolaan mapping, monitoring flaky test, dan validasi berkala agar tidak melewatkan regresi baru. Selalu kombinasikan dengan sanity check untuk menjaga dasar kualitas.

Dengan menggabungkan identifikasi jalur regression-critical, seleksi tes berdasarkan perubahan, serta perawatan flaky test, pipeline CI/CD menjadi lebih efisien tanpa mengorbankan pengawasan terhadap regresi. Pastikan metrik, tooling, dan proses review disesuaikan dengan kompleksitas proyek agar test impact analysis benar-benar membantu menjaga kualitas kode.