Untuk menjawab masalah flaky test di CI, fokuskan dulu pada penataan ulang test suite sehingga setiap eksekusi dapat diandalkan. Dalam artikel ini dibahas cara mengevaluasi prioritas kasus, mengelompokkan pengujian menurut frekuensi kegagalan, menerapkan strategi isolasi per test, memanfaatkan metrik pass rate dan lonjakan durasi, serta memanfaatkan alat observabilitas dan umpan balik ke backlog regression.

Menata Ulang Test Suite untuk Menangkal Flaky Test di CI

Pertanyaan inti—bagaimana membuat test suite CI tidak mudah goyah karena flaky test—dijawab dengan pemetaan ulang test sesuai risiko dan perilaku historisnya. Mulailah dengan memahami test mana yang paling sering gagal secara nondeterministik, lalu alokasikan kembali sumber daya dan pengawasan untuk mengurangi dampaknya.

1. Evaluasi Prioritas Kasus Berdasarkan Dampak Bisnis

Setiap kasus tes perlu diberi skor prioritas tidak hanya berdasarkan fungsinya, tapi juga dampaknya bila gagal. Buat matriks sederhana yang memetakan nilai bisnis terhadap frekuensi kegagalan nondeterministik. Contoh kolom:

  • Nilai bisnis: fitur kritis seperti pembayaran diberi skor tinggi.
  • Riwayat flaky: jumlah rerun dalam 30 hari terakhir.
  • Waktu eksekusi: pengujian yang berat harus dikurangi gangguannya.

Hasilnya adalah daftar prioritas yang memandu pengujian mana yang harus diobservasi lebih lanjut, mana yang bisa dipindah ke lingkungan terkontrol, dan mana yang harus dicatat sebagai regression backlog.

2. Pembagian Pengujian Berdasarkan Frekuensi Kegagalan

Berdasarkan data, pisahkan pengujian ke dalam tiga kategori: stable, suspect, dan flaky. Terapkan aturan otomatis:

  • Stable: jalankan bersamaan dengan pipeline utama.
  • Suspect: jalankan setelah merge, tambahkan retry terbatas dan log tambahan.
  • Flaky: pindahkan ke run khusus dengan isolasi, capture log, dan notifikasi tim QA.

Pipeline CI bisa dikonfigurasi untuk mengeksekusi kategori ini secara berbeda, misalnya dengan menggunakan stage terpisah atau label khusus (misalnya di GitHub Actions dengan if: contains(matrix.category, 'flaky')).

3. Strategi Isolasi Per Test

Untuk mengurangi interferensi, isolasi setiap test menggunakan:

  • Mocking atau virtualisasi: pastikan dependensi eksternal (API, DB) dijadikan dummy ketika memungkinkan.
  • Reset state: jalankan cleanup berupa database truncate, cache flush, environment reset.
  • Provider containerized: batasi bagian yang membuat jaringan bersama dengan test runner terpisah.

Contoh implementasi di pipeline:

jobs:
  flaky-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Setup
        uses: actions/checkout@v3
      - name: Start isolated database
        run: docker-compose -f docker-compose.test.yml up -d db
      - name: Run flaky suite
        run: pytest tests/flaky --maxfail=1 --junitxml=flaky-results.xml

Penjelasan: group flaky dijalankan dalam job terpisah untuk menghindari gangguan state dari job lain, dengan reposisi database tersendiri.

4. Peran Metrik Pass Rate dan Lonjakan Durasi

Gunakan metrik pass rate untuk mendeteksi regressi di tengah pipeline. Dasbor sederhana bisa memperlihatkan tren pass rate per job selama 14 hari terakhir. Jika pass rate turun secara signifikan atau menunjukkan fluktuasi tinggi, langkah pertama adalah menandai job tersebut untuk review prioritas.

Selain pass rate, monitor lonjakan durasi setiap job. Flaky test sering menyebabkan timeout atau eksekusi jauh lebih lama. Catat durasi rata-rata dan kirim notifikasi ketika lonjakan melebihi threshold (misalnya +30%). Kombinasi metrik ini membantu menentukan apakah flaky diakibatkan oleh masalah deterministik atau infrastruktur.

5. Observabilitas dan Deteksi Flake

Gunakan alat observabilitas seperti Grafana/Loki untuk melihat log kegagalan, Datadog test monitoring, atau layanan test intelligence (misalnya Testim, ReportPortal) yang bisa mendeteksi pola flaky dari rerun otomatis. Integrasi log level per test (misalnya tagging [flaky]) mempermudah pencarian.

Contoh observabilitas sederhana: Data pipeline mengirim metrik ke Prometheus, dan Grafana menampilkan panel dengan:

  • Pass rate per job.
  • Jumlah rerun per test.
  • Durasi rata-rata vs threshold.

Ketika terjadi spike, tim bisa langsung membuka dashboard untuk melihat log yang terkait, lalu menentukan apakah perlu isolasi tambahan atau perbaikan kode.

6. Integrasi Feedback ke Backlog Regression

Setiap kali flaky test terdeteksi dan tidak bisa segera diselesaikan, catat dalam backlog regression dengan label jelas seperti flaky-test atau ci-stability. Sertakan konteks seperti job, commit, log error, dan versi environment.

Workflow yang disarankan:

  1. CI mengirim notifikasi lewat issue tracker (misalnya GitHub Issue atau Jira) dengan metadata test frustration.
  2. Tim QA menempatkan tiket di backlog regression, memberi prioritas berdasarkan dampak bisnis dan frekuensi.
  3. Setiap sprint review, evaluasi tiket ini untuk menentukan apakah isolasi atau perbaikan lebih cost-effective.

Dengan cara ini, feedback loop dari pipeline ke backlog tidak hanya memastikan flaky ditindaklanjuti tapi juga membantu mengukur kemajuan dalam meningkatkan stabilitas CI.

Kesimpulan

Menata ulang test suite untuk menekan flaky test adalah kombinasi analisis data historis, pengelompokan uji berdasarkan perilaku, isolasi yang konsisten, metrik observabillity, dan proses feedback yang tertata. Dengan pendekatan ini, CI bisa lebih tangguh, developer tidak lagi dibebani rerun manual, dan tim memiliki urgensi yang jelas untuk memperbaiki area bermasalah.