Test Impact Analysis (TIA) langsung menjawab pertanyaan: bagaimana memilih uji yang benar-benar relevan setelah perubahan kode? Dengan TIA, pipeline tidak lagi menjalankan seluruh suite, melainkan fokus pada uji yang dipengaruhi, sehingga regresi bisa terdeteksi cepat tanpa membebani waktu eksekusi.

Kita akan melihat data apa yang diperlukan, bagaimana area terdampak dikenali, serta alur otomatisasi lengkap dalam CI/CD, termasuk strategi menghadapi flaky tests agar analisis tidak kacau.

Memahami Test Impact Analysis

TIA adalah strategi yang menghubungkan perubahan kode dengan suite uji yang relevan. Intinya, jika sebuah file sumber hanya digunakan oleh fitur tertentu, maka hanya uji terkait yang dijalankan. Strategi ini penting di pipeline besar karena menjaga regresi tetap terdeteksi sambil menyingkat waktu feedback dan sumber daya.

Data Pendukung yang Dibutuhkan

  • Coverage data: mencatat jalur eksekusi setiap uji. Ini memungkinkan peta ketergantungan antara file dan uji.
  • Dependency graph: memahami hubungan antar modul, paket, atau komponen backend/front-end. Tanpa ini, perubahan diuji secara dangkal.
  • Perubahan kode: diff dari commit atau branch. TIA menggunakan daftar file yang berubah untuk mencari uji terpengaruh melalui data coverage dan dependency.

Ketiga data tersebut bisa dikumpulkan masing-masing di tahap build: coverage melalui alat seperti JaCoCo atau Coverage.py, dependency lewat pipeline analyzer, dan diff dari sistem kontrol versi.

Mengenali Area Terdampak

Setelah data terkumpul, langkah berikutnya adalah menentukan area terdampak. Caranya:

  1. Identifikasi file dan paket yang berubah dari diff.
  2. Gunakan data dependency untuk melacak modul dependent dan transitive.
  3. Mapping data coverage untuk menentukan test suite yang menutupi file-file tersebut.

Jika aplikasi monolitik, cukup mapping file ke test. Di arsitektur mikroservis atau front-end dengan bundler, tambahan metadata seperti endpoint atau bundler chunks membantu menentukan dampak.

Alur Otomatisasi TIA di CI/CD

Berikut alur otomatisasi ideal TIA:

  1. Mengumpulkan metadata: Build pertama-tama compilasi dan menjalanin coverage runner untuk merekam uji vs file.
  2. Menandai suite terpengaruh: Algoritma membandingkan diff vs coverage/dependency, lalu menandai test suite.
  3. Membandingkan baseline vs only-impacted: Jalankan baseline (biasanya nightly/full suite) setelah itu jalankan hanya impacted tests untuk validasi cepat.
  4. Mengomunikasikan hasil: CI mengirimkan laporan yang menyertakan test mana yang berjalan, statusnya, dan alasan pemilihannya.

Contoh Skrip Penyederhanaan Workflow

Berikut contoh skrip shell yang membaca file metadata dan menghasilkan daftar test impacted:

#!/bin/bash
CHANGED_FILES=$(git diff --name-only origin/main...HEAD)
readarray -t IMPACTED_TESTS < <(python3 scripts/find_impacted_tests.py "$CHANGED_FILES")

if [ ${#IMPACTED_TESTS[@]} -eq 0 ]; then
  echo "Tidak ditemukan uji terdampak, jalankan smoke test minimal."
  exit 0
fi

printf '%s\n' "${IMPACTED_TESTS[@]}" > impacted_tests.txt
xargs -a impacted_tests.txt -n 1 pytest

Skrip ini mengandalkan utilitas Python untuk menggabungkan coverage metadata. File impacted_tests.txt digunakan CI untuk memicu ulang uji relevan.

Memastikan Baseline vs Hanya Terpengaruh

Setelah impacted tests dijalankan, bandingkan hasilnya dengan baseline sebelumnya guna memastikan tidak ada regresi baru. Jika impacted tests lulus, Anda bisa berasumsi area tersebut aman sementara suite lengkap dapat dijadwalkan di luar siklus kritikal.

Menangani Flaky Tests dalam TIA

Flaky tests menimbulkan sinyal palsu dan mengganggu TIA karena menentukan area terdampak menjadi tidak jelas. Cara menanganinya:

  • Deteksi: Jalankan impacted tests beberapa kali dalam mode rerun, catat ketidakstabilan statistik.
  • Isolasi: Tandai sebagai flaky dan keluarkan dari TIA sementara (quarantine). Jalankan secara terpisah dengan tracing tambahan.
  • Remediasi: Prioritaskan debugging flaky tests menggunakan log lengkap, rollback dependency, atau mock stabil.

Tanpa pengelolaan ini, TIA bisa “menganggap” test sebagai terpengaruh padahal hasilnya tidak dapat diandalkan. Komunikasikan status flaky di laporan CI agar tim tidak menunggu feedback palsu.

Tools dan Integrasi yang Biasa Digunakan

Beberapa alat yang mendukung TIA:

  • Azure DevOps Test Impact Analysis: Menyediakan telemetry penentuan test impacted di pipeline .NET.
  • Gradle Test Selection: Memiliki plugin yang memilih test berdasar perubahan file.
  • Custom Coverage Store: Menyimpan mapping test dengan coverage di database sederhana (misalnya PostgreSQL atau S3) untuk digunakan oleh skrip.

Dalam pipeline Anda sendiri, cukup integrasikan script penyimpanan metadata dan langkah decision-making sebelum fase test. Pastikan metadata selalu diperbarui agar keputusan TIA tetap akurat.

Trade-off dan Pertimbangan

Beberapa hal yang perlu diperhatikan:

  • Ketelitian vs waktu: TIA menghemat waktu test tapi memerlukan investasi dalam pengumpulan metadata dan pemeliharaan dependency graph.
  • Apalagi jika perubahan besar: Jika diff mencakup banyak modul, ada risiko impacted tests hampir sama dengan suite penuh. Dalam kasus ini, jalankan baseline lengkap untuk memastikan stabilitas.
  • Observabilitas data: Pastikan coverage dan dependency graph dapat direkonsiliasi dengan cepat agar TIA tetap akurat.

Kesimpulannya, TIA memungkinkan pipeline besar tetap responsif dengan memilih uji fokus. Automasi metadata, pemetaan impacted tests, serta penanganan flaky tests adalah fondasi yang membuat strategi ini berhasil dalam mencegah regresi.