Rust: Blueprint Verifikasi CI untuk Cegah Regresi Layanan Async menjelaskan bagaimana menyusun pipeline verification sebelum deploy agar regresi layanan async terdeteksi lebih awal. Fokusnya pada pemetaan jenis tes, strategi ordering dan gating, serta mekanisme menangani flaky test pada layanan Tokio/hyper.

Memetakan Jenis Test untuk Layanan Async

Tim Rust harus membedakan antara unit test, integration test, smoke test, dan regression test. Tujuan utama adalah menutup permukaan berbahaya tanpa memperlambat delivery tidak perlu.

  • Unit Test: fokus pada logika sinkron/async tertentu (misal future yang menjalankan decoding request). Jalankan secara lokal dan di CI stage paling awal.
  • Integration Test: validasi interaksi Tokio runtime dengan Hyper service, termasuk middleware, tracing, dan metrics. Gunakan fixture runtime di tests/ dengan #[tokio::test].
  • Smoke Test: health check end-to-end (misal request HTTP sederhana) setelah service dijalankan di container atau simulasi localstack.
  • Regression Test: tes yang mengekspose bug historis, kadang bergantung pada workload non-deterministik. Tempatkan di pipeline tersendiri atau aktifkan di nightly run dengan tagging khusus.

Mengelompokkan tes memungkinkan CI memprioritaskan dan mengisolasi run di stage terpisah.

Strategi Pengurutan dan Gating dalam Pipeline CI

Untuk layanan async berbasis Tokio/hyper, pipeline harus mencerminkan ketergantungan antar jenis tes:

  1. Stage 1 – Fast Unit Test: jalankan cargo test --lib dan tes crate helpers. Hentikan pipeline jika gagal karena selain kesalahan sintaks/logic dasar, tidak ada layanan async nyata.
  2. Stage 2 – Integration Test Fokus I/O: gunakan fitur tokio multi-threaded. Misal cargo test --test http_routing -- --test-threads=1 untuk meminimalkan race saat memeriksa stack Hyper.
  3. Stage 3 – Smoke Test Containerized: deploy container dengan service, lalu panggil endpoint health. Stage ini digating-kan pada release branch, memastikan build test isolasi dengan true async path.
  4. Stage 4 – Regression & Flaky Investigation: jalankan test regression dengan tagging; bisa dijalankan manual atau nightly jika risiko rendah.

Pada tiap stage, gunakan gating: stage berikutnya hanya berjalan jika semua tes sebelumnya lulus. Ini mencegah regression dari terjadi bila ada regresi fundamental.

Tagging dan Penanganan Flaky Test

Pada repositori Rust yang besar, flaky test sering muncul karena concurrency timing. Kunci: tagging dan marker.

  • Tagging: gunakan atribut seperti #[ignore = "flaky:tokio-sleep"] untuk menandai test yang tidak stabil. CI harus mengetahui bahwa test tersebut butuh rerun khusus.
  • Flaky Marker: buat skrip yang memindai output test untuk kata kunci flaky dan mengirim ke dashboard retrace (misal Sentry atau custom log aggregator).
  • Restart Strategi: otomatis rerun test yang gagal karena flakiness, tetapi hanya di stage regression/ nightly. Hal ini mencegah rerun berlebih di stage kritis.

Dengan metadata ini, tim bisa memisahkan noise dari failures yang benar-benar perlu perhatian.

Mekanisme Retrace untuk Flaky Test

Ketika flaky test mendeteksi failure, perlu konteks lengkap agar bisa direproduce. Pendekatan berikut membantu:

  • Environment Snapshot: log variabel seperti RUST_BACKTRACE, RUST_LOG, dan versi crate terkait runtime (meskipun stable).
  • Seeding: bila test bergantung pada random data, buat bagian assert yang log tokio::time::Instant::now() dan seed deterministic melalui rand_chacha::ChaCha8Rng::seed_from_u64().
  • Trace Logs: aktifkan tracing level pada module yang diuji. Contohnya, saat Hyper menolak connection, sertakan log request/response header untuk melihat sequence async.
  • Artifact Snapshot: simpan output container (misalnya curl -v localhost:3000/health) sehingga insinyur sudah punya data saat bug dilaporkan.

Data ini penting untuk mengurangi waktu retrace tanpa harus menunggu failure berikutnya.

Contoh Skenario Layanan Tokio/Hyper

Bayangkan layanan Hyper yang menerima request JSON, memanggil service async lain, lalu menulis ke Postgres. Gunakan pipeline seperti berikut:

name: Rust CI Blueprint
on: [push, pull_request]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions-rs/toolchain@v1
        with:
          profile: minimal
          toolchain: stable
      - name: Run Unit Tests
        run: cargo test --lib
      - name: Run Integration Tests
        run: cargo test --test hyper_routes -- --test-threads=1
      - name: Smoke Test Service
        run: |
          docker build -t svc-test .
          docker run -d --name svc svc-test
          sleep 5
          curl -sSf http://localhost:8080/health
      - name: Regression Flaky Marker
        if: github.ref == 'refs/heads/main'
        run: |
          cargo test --test regression_timeout -- --ignored || true

Perhatikan stage smoke memverifikasi endpoint health sederhana. Stage regression hanya dijalankan di main branch, dan failure tidak langsung memblokir tapi dikumpulkan untuk evaluasi.

Tips Debugging dan Trade-offs

Tim harus bertanya apakah test benar-benar menutup regressi penting:

  • Trade-off Waktu vs Coverage: menambahkan terlalu banyak integration/regression test bisa memperlambat pipeline. Gunakan selective gating untuk branch release saja.
  • Debugging Async: ketika race terjadi, aktifkan RUST_LOG=tokio=debug,hyper=debug untuk melihat scheduling executor.
  • Flaky Source: seringkali terkait timeouts. Pertimbangkan mengganti tokio::time::sleep dengan tokio::time::timeout yang terdokumentasi agar test lebih deterministik.

Dengan blueprint ini, tim Rust dapat mengontrol regresi layanan async secara sistematis dan mengurangi noise dari flaky test.