Flaky test bisa merusak kepercayaan terhadap pipeline CI jika tidak segera ditangani. Artikel ini menunjukkan cara membangun observabilitas automasi, retri terukur, dan workflow verifikasi untuk mencegah regresi flaky test sekaligus menjaga fokus tim pada perbaikan akar masalah.

Rangka pendekatan ini meliputi pemetikan sinyal dari log dan metrik kestabilan, menetapkan retri hanya pada kasus kredibel, memvalidasi ulang dengan trigger tambahan atau dogfooding, serta menandai hasil test agar dapat membedakan kejadian flaky vs gagal nyata.

Pemahaman spesifik terhadap flaky test di CI

Flaky test adalah pengujian yang hasilnya tidak konsisten terhadap kode dan lingkungan yang sama. Dalam pipeline CI, flake biasanya muncul karena ketergantungan eksternal (database, API) yang bergolak, timeout yang terlalu ketat, urutan paralel yang tidak deterministik, atau cache/data yang tersisa setelah build sebelumnya.

Tujuan strategi preventif bukan hanya mengeksekusi ulang hingga lulus, tetapi mengidentifikasi pola sebelum test yang tidak stabil memblokir merge. Oleh sebab itu, kita perlu observabilitas mendalam dan proses dokumentasi agar flake dikelola secara sistematis.

Observabilitas automasi untuk mendeteksi flake

Observabilitas menyediakan konteks yang diperlukan untuk menilai apakah kegagalan test bersifat flake. Dua lapisan utama adalah log terstruktur dan metrik kestabilan.

Log terstruktur dan konteks pipeline

Pastikan setiap job CI menyertakan informasi seperti commit hash, environment variables, versi dependency, dan status sumber daya eksternal. Simpan log dengan struktur yang memudahkan query (JSON, key-value). Sertakan label tambahan seperti test-suite, node-id, dan retry-count sehingga bila terjadi gagal, tim bisa melihat pola—apakah selalu terjadi pada node tertentu, waktu tertentu, atau setelah retri ke sekian.

Contoh snippet log dengan struktur JSON (misalnya di Node.js):

console.log(JSON.stringify({
  suite: 'integration/payment',
  phase: 'setup',
  env: process.env.NODE_ENV,
  node: process.env.CI_NODE_INDEX,
  message: 'setup db connection',
  durationMs: 320
}));

Format seperti ini memudahkan pencarian lewat observability platform (Grafana Loki, Elastic, dsb.) dan mendeteksi apakah kegagalan tersebar atau terlokalisir.

Metrik kestabilan sebagai sinyal regresi

Bangun dashboard metrik yang memantau jumlah rerun initiated, rerun bertahan (gagal dua kali berturut-turut), dan waktu rata-rata eksekusi per job. Tambahkan metrik tambahan seperti flaky rate per suite (jumlah rerun/total run) dan median wait time untuk sumber daya eksternal.

Perhatikan segmen berikut untuk sinyal regresi:

  • Pola spike rerun: Saat rerun job meningkat tajam, artinya ada masalah lingkungan atau ketergantungan.
  • Persisten failure di node tertentu: Menunjukkan variabilitas hardware atau sisa state.
  • Lama eksekusi naik: Bisa jadi karena setup ulang lingkungan, yang menandakan determinisme berkurang.

Dengan metrik ini, alert dapat diatur untuk memberi tahu tim QA atau SRE sebelum flaky test menghambat merge.

Retri selektif dan perbaikan akar masalah

Re-run otomatis tidak boleh menjadi solusi default. Terapkan aturan selective retry agar hanya test-suite yang diketahui sensitif terhadap flake yang mendapatkan retri dan hanya di level tertentu.

Contoh konfigurasi pipeline (YAML generic):

jobs:
  integration-tests:
    stages: [test]
    script:
      - npm run test:integration
    retry:
      max: 1
      when:
        - pipeline_failed
    rules:
      - if: '$CI_COMMIT_BRANCH == "main"'
        retry:
          max: 1
        when: on_failure

Dalam pipeline di atas, retry dibatasi maksimal satu kali dan hanya dipicu bila kegagalan umum (bukan error konfigurasi). Aturan lebih lanjut bisa memakai metadata test seperti tag [flaky] atau [expensive] agar retri hanya terjadi pada kasus yang telah dianalisis sebelumnya.

Setiap kali retri berhasil, catat context tersebut setelah analisis sebab (misalnya konkuren akses datastore). Gunakan dokumentasi internal untuk mencatat pola per test-suite dan tindakan lanjutan (misalnya: increase timeout atau mock external API).

Workflow verifikasi tambahan dan dogfooding

Memastikan flaky test tidak kembali membutuhkan workflow verifikasi tambahan.

  • Trigger uji tambahan: Setelah build gagal di stage penting, otomatis jalankan test-suite pada runner berbeda sebelum memasang label gating. Ini memastikan kegagalan itu nyata atau hasil flake.
  • Dogfooding: Tim QA atau developer menjalankan test-suite di cabang feature yang sama dalam environment local/cluster mereka sebelum PR merge. Hasil ini divalidasi dan ditautkan ke job CI untuk referensi manual.

Workflow ini bisa diotomasi dengan menyimpan verification artifacts (log, screenshot, metrics) yang ditautkan ke tiket issue. Jika verifikasi menyatakan kegagalan flaky, jangan langsung merge; buat catatan root cause dan arahkan perbaikan.

Membedakan flaky test dan gagal nyata lewat dokumentasi dan tagging

Tagging hasil test dan dokumentasi membantu tim memprioritaskan usaha pemulihan. Gunakan sistem tagging berikut:

  • [flaky] untuk kasus yang pernah gagal dan lulus setelah retri 1-2 kali.
  • [blocking] bila gagal menandakan bug konsumen.
  • [external] bila kegagalan disebabkan ketergantungan eksternal.

Setiap tag harus disertai catatan root cause: contoh, flaky due to race condition on cache invalidation. Simpan di dokumen shared (wiki atau issue tracker) yang memuat langkah pengecekan, rerun, dan mitigasi khusus. Ini mempercepat debugging dan menumbuhkan pengetahuan lintas tim.

Tinjauan trade-off dan troubleshooting umum

Strategi ini memang menambah kompleksitas observabilitas dan dokumentasi. Namun, biaya tambahan tersebut sebanding dengan pengurangan waktu yang tersita untuk menunggu rerun manual.

Beberapa jebakan umum yang perlu dihindari:

  • Menerapkan retry tanpa batas karena hanya menyembunyikan regression.
  • Mengandalkan logs tanpa struktur yang memadai, sehingga sulit melacak pola.
  • Mengabaikan dokumentasi root cause sehingga setiap tim mengulangi analisis yang sama.

Untuk debugging, mulai dari log terstruktur (apakah node, env, atau resource external konsisten), periksa metrik stabilitas (apakah spike rerun baru), lalu lihat status rerun dan tag yang dikenakan. Dari situ, tentukan apakah perlu perbaikan kode, environment, atau konfigurasi pipeline.

Ringkasan implementasi

Implementasi strategi preventif flaky test CI melibatkan:

  1. Observabilitas menyeluruh: log terstruktur dan metrik kestabilan.
  2. Retri selektif yang terbatas dan didasarkan pada metadata test.
  3. Workflow verifikasi tambahan seperti trigger tambahan dan dogfooding.
  4. Dokumentasi/tagging hasil test agar tim dapat membedakan flaky vs genuine failure.

Dengan pendekatan ini, tim dapat menjaga pipeline CI tetap handal, fokus memperbaiki akar masalah, dan menghindari false-positive yang mengurangi kecepatan pengembangan.