Strategi regression testing untuk pipeline compiler harus langsung menjawab pertanyaan: bagaimana menjaga stabilitas fungsional dan performa setiap kali kita merilis perubahan di bagian frontend, middle, maupun backend optimizer. Dalam pendekatan ala CS6120, fokusnya adalah pengujian berlapis, deteksi flaky test di fase optimasi, dan otomasi suite regression agar rollback dapat dihindari.

Pengujian Berlapis di Pipeline Compiler

Pipeline compiler terdiri dari banyak fase (parsing, middle-end optimizations, codegen). Strategi regression testing yang efektif memisahkan level-level ini agar failure mudah ditelusuri.

Unit Test: Verifikasi Fungsi Kecil

Unit test memvalidasi behavior serializer AST, pass scheduling, dan transformasi sederhana. Setiap commit harus memastikan fungsi-fungsi utility tidak merusak invariants dasar. Checklist verifikasi mencakup:

  • Input AST minimal ditransformasikan sesuai spec.
  • Invariant menggunakan fuzzer deterministik untuk memeriksa kesalahan memori.
  • Metrik coverage meliputi branch pada transformasi utama (misalnya, jumlah path lintasan pada pass scheduler).

Metrik coverage dipantau dengan tooling yang mampu mengaitkan line coverage dengan pass-specific code, sehingga kalau coverage turun evaluasi risiko dilakukan sebelum merging.

Integration Test: Interaksi Antar Pass

Berikutnya, integration test mengecek serangkaian pass berurutan. Fokusnya adalah memastikan optimisasi tidak menyimpang saat ada dependensi global. Checklist:

  • Suite input menerapkan kombinasi opt level (--O2, --O3).
  • Perbandingan output IR sebelum dan sesudah pass untuk deteksi semantic drift.
  • Peringatan deterministik: deteksi undefined behavior deterministik seperti perhitungan off-by-one yang dikomplain compiler sanitizers.

Loop ini paling pas ditempatkan dalam job terpisah agar integration build bisa memanfaatkan snapshot shared cache dependencies.

End-to-End Test: Dari Source ke Binary

End-to-end regression memastikan keseluruhan pipeline tetap menghasilkan binary yang sesuai. Gunakan benchmark kecil tetapi representatif, dan verifikasi dengan:

  • Reproducible build (same seed dan timestamp) untuk mendeteksi flake deterministik.
  • Functional assertion via interpreter/reference backend.
  • Coverage indicator: persentase kode compiler yang dilalui dari entry point hingga emission.

Dengan layer-layer ini, bug kecil di pass optimization tidak langsung membuat end-to-end test gagal tanpa informasi yang cukup.

Deteksi dan Isolasi Flaky Test di Fase Optimasi

Optimasi compiler sering berperilaku non-deterministik akibat timing, memory layout, atau dependency eksternal. Untuk mencegah flaky test merusak regression suite:

  • Lacak histografi hasil test dengan seed yang disimpan per hash commit.
  • Tambahkan sanity check deterministik di optimasi (misalnya assertions di IR invariants) agar kegagalan bisa direproduksi saat metadata tidak konsisten.
  • Gunakan rerun prioritization: saat test gagal, ulangi 3 kali; jika hasil tidak konsisten, tandai sebagai flaky dan jangan langsung berlaku gating—pengembang diberi notif lintas tim.

Penanganan gagal: isolasi dengan membatasi pass yang aktif. Jika rerun pertama dan ketiga berbeda, jalankan test dengan subset pass tertentu (misalnya hanya pass yang memodifikasi loop nest) untuk mempersempit sumber flake.

Automasi Regression Suite untuk Mencegah Rollback

Automasi regime regression suite memastikan tidak ada push yang melampaui threshold kualitas dan mengurangi kebutuhan rollback manual.

Contoh runner sederhana di CI:

#!/usr/bin/env bash
set -euo pipefail
./scripts/build-compiler --mode=dbg
./regression/run-suite --layers=unit,integration --opt-level=O2
if ! ./regression/run-suite --layers=e2e --opt-level=O3 --allowed-flaky=0; then
  echo "End-to-end suite failed. Collecting artifacts..."
  ./scripts/collect-diagnostics
  exit 1
fi

Pipeline ini secara otomatis mengeksekusi regression suite setiap merge ke main branch. Setelah failure, job akan mengunggah logs, artifact IR, dan diffs pass untuk dibagikan ke tim.

Automasi juga perlu memonitor metrik coverage per job. Misalnya, job integration harus memvalidasi bahwa setidaknya 85% graham coverage pass scheduler tercapai; jika turun, job tidak langsung gagal tetapi mengirim peringatan kepada pemilik pass yang dievaluasi.

Perlu dipahami trade-off: menambah lapisan cek memperpanjang waktu pipeline. Untuk itu, pembangunan caching artifact dan selective suite (fast path vs deep path) memberikan keseimbangan antara kecepatan dan kedalaman validasi.

Checklist Verifikasi dan Integrasi CI/CD

Setiap fases regression testing memiliki checklist verifikasi yang harus dipenuhi sebelum merging:

  • Unit: semua pass unit harus melewati dynamic invariants dan coverage threshold.
  • Integration: output IR tidak mengalami semantic drift, dan deterministic warning (seperti undefined behaviour) harus nol.
  • End-to-end: binary output sesuai reference, builder reproduksi memadai.

Tips Integrasi ke CI/CD

Agar stabilitas pipeline compiler selalu terpantau:

  1. Implementasikan gating job yang menjalankan regression suite sebelum merge. Gunakan CI job matrix untuk mengkombinasikan target platform dan opt level.
  2. Pasang alert per metric drop (coverage, deterministic warnings). Misalnya, jika deterministic warning di phase optimization meningkat, kirim notifikasi ke channel tim compiler.
  3. Gunakan dashboard pemantauan untuk melihat trend failure per fase. Saat regression suite stabil, catat baseline runtime dan flake rate.
  4. Integrasikan test artifact (IR snapshots, logs) ke issue tracker saat failure agar debugging lebih cepat.

Dengan pendekatan ini, regression testing menjadi mekanisme proaktif: bukan hanya mendeteksi bug, tetapi memberi konteks detil untuk memperbaiki riwayat perubahan.

Kesimpulan

Strategi regression testing ala CS6120 memanfaatkan pengujian berlapis, isolasi flaky test, automasi regression suite, dan integrasi CI/CD agar compiler pipeline tetap stabil. Memahami trade-off antara kedalaman testing dan waktu eksekusi, serta memantau metrik seperti coverage dan deterministic warning, memastikan setiap perubahan tetap terverifikasi tanpa menundukkan tim pada rollback mendadak.