Untuk menjaga stabilitas proyek Rust, strategi verifikasi regresi dengan smoke test otomatis harus memastikan bahwa perubahan baru tidak merusak jalur paling kritikal. Artikel ini membahas langkah-langkah praktis mulai dari identifikasi area sensitif hingga pengemasan smoke suite ke pipeline CI, sehingga tim bisa cepat triase saat ada kegagalan.

1. Identifikasi Area Regresi Dan Smoke Test Utama

Membangun suite smoke berarti memilih fitur paling krusial yang harus selalu lulus. Dalam konteks Rust, utamakan layer berikut:

  • API publik (crate exports) yang digunakan downstream.
  • Database migrations atau perubahan schema yang dijalankan otomatis.
  • Interaksi dengan sistem eksternal seperti message broker atau file I/O penting.

Gunakan matriks risiko untuk menentukan test apa yang menguji area ini, misalnya proyek yang menyediakan CLI harus memvalidasi flag utama dan output sebelum membuka release.

1.1 Fokus pada jalur gagal paling mahal

Smoke suite tidak perlu memeriksa semua kombinasi parameter. Pilih satu scenario representatif per fitur kritis (misalnya: startup default, auth flow, persistence write-read). Tujuan utama adalah mendeteksi regresi fatal, bukan memastikan 100% coverage.

2. Perbedaan Unit Smoke vs Integration Smoke

Smoke test terbagi menjadi dua kategori utama:

  • Unit smoke: memanggil fungsi atau modul secara isolated untuk memvalidasi behavior dasar tanpa dependency eksternal.
  • Integration smoke: mengeksekusi alur end-to-end dengan service dependency (database, filesystem, jaringan internal).

Unit smoke cocok dijalankan setiap commit karena cepat, sementara integration smoke bisa dipicu lebih jarang atau setelah build tertentu karena memerlukan setup lebih kompleks.

2.1 Contoh pengelompokan

  • Unit smoke: crate core memanggil Config::load(), memastikan default path terbaca.
  • Integration smoke: menjalankan binary dengan cargo run --bin server -- --env=staging lalu memeriksa endpoint health.

Perlu membedakan hasil reporting agar CI bisa menunjukkan jenis kegagalan yang terjadi.

3. Pemanfaatan cargo test dan cargo nextest

cargo test tetap alat dasar, tapi cargo nextest menawarkan paralelisme dan laporan lebih kaya. Strategi：

  • Gunakan cargo test --test smoke_core untuk unit smoke terfokus.
  • Untuk integrasi, buat target cargo nextest run -p smoke-suite agar dapat mengontrol level paralelisasi.

Tips: segmentasikan smoke tests ke dalam crate khusus (misalnya tests/smoke/) agar mudah dipanggil dari pipeline.

3.1 Konfigurasi nextest minimal

[profile.stable]
parallel = 4
output = "minimal"
report-dir = "target/nextest"

Penyesuaian parallel membantu menghindari kompetisi resource saat pipeline dijalankan di runner CI terbatas.

4. Packaging Smoke Suite dalam CI untuk Triase Cepat

Pertahankan pipeline yang memisahkan pengujian smoke paling awal. Contoh alur:

  1. Stage pertama: cargo build + cargo test --lib --test smoke_core.
  2. Jika lulus, lanjutkan ke cargo nextest run -p smoke-suite.
  3. Stage terakhir: load integration lebih berat atau nightly tests.

Jika smoke suite gagal, CI harus berhenti dan menampilkan log yang jelas. Prioritaskan report dari target/nextest agar QA/engineer bisa melihat stack trace dan environment variable yang digunakan.

4.1 Observabilitas hasil smoke

Rekomendasi:

  • Simpan artifact log tiap smoke run (misalnya target/nextest/logs).
  • Tag hasil dengan status environment seperti branch/main atau release candidate.
  • Gunakan badge CI khusus untuk smoke (contingent status).

Catatan: konsistensi naming memudahkan triase dan memisahkan noise dari tests lainnya.

5. Teknik Mendeteksi dan Menanggulangi Flaky Test

Smoke suite harus stabil karena fungsinya triase cepat. Untuk menangani flaky test：

  • Gunakan counter retries di nextest (retries = 2) hanya untuk test yang sudah diidentifikasi flaky, sertakan label.
  • Catat waktu eksekusi, heap allocation, dan dependency network untuk melihat pattern tanda flake.
  • Isolasi state (misalnya gunakan tempdir per test) agar tidak bergantung pada urutan.

Jika flaky tetap muncul, pertimbangkan menghapus test dari smoke suite dan pindahkan ke regression suite yang dijalankan jarang. Smoke harus mencerminkan kepercayaan tinggi.

6. Langkah Verifikasi Manual Terbatas

Smoke suite otomatis mengurangi kebutuhan cek manual, tapi verifikasi manual terbatas tetap diperlukan terutama untuk integrasi kompleks:

  • Setiap failure smoke, engineer memeriksa output cargo nextest dan menjalankan ulang secara lokal.
  • Pastikan manual test checklist minimal: inisialisasi environment, health check endpoint, dan gateway auth.
  • Gunakan dokumentasi checklist untuk memandu triase: "Apa modifikasi terakhir?" "Apakah dependency external upstream berubah?"

Manual check membantu memastikan tidak ada false negative akibat masalah environment runner.

Kesimpulan

Smoke test regresi di Rust tidak harus kompleks, asalkan fokus pada area kritikal, memisahkan unit dan integration, memanfaatkan cargo test/cargo nextest, dan mengemas suite ke dalam pipeline CI dengan observabilitas yang memadai. Tambahkan strategi deteksi flaky dan prosedur manual singkat untuk memastikan suite tetap relevan, sehingga CI tetap dapat diandalkan sepanjang siklus pengembangan.