Masalah utama yang ingin diselesaikan artikel ini adalah memastikan API Go Fiber stabil menjelang rilis dengan cara mengecek flaky test dan regression secara sistematis. Dalam 1-2 paragraf pertama, ringkasnya: we need a checklist yang memadukan identifikasi flaky behavior, pendekatan regression berdasarkan risiko, metrik deteksi dini, serta integrasi ke pipeline CI/CD agar release bisa dilaksanakan dengan confident.

Pendekatan ini penting bagi tim yang mengandalkan test suite otomatis untuk mengawasi API Go Fiber sehari-hari tanpa terganggu fluktuasi lingkungan atau false positive.

1. Checklist Primer untuk Verifikasi Sebelum Rilis

Pertama-tama siapkan daftar verifikasi yang dijalankan baik secara manual sebelum release candidate maupun otomatis di pipeline. Checklist dapat mencakup:

  • Stabilitas suite end-to-end: jalankan subset test yang mencerminkan jalur kritis (auth, CRUD utama) minimal dua kali berurutan untuk mengendus flaky test.
  • Regression build: pastikan ada baseline commit/branch yang dianggap stabil lalu bandingkan hasil test terbaru terhadap baseline itu.
  • Environment sanity: validasi parameter konfigurasi (misal DB URL, ENV) agar tidak berubah dan menyebabkan false positive.
  • Health check API: panggil endpoint /health dan periksa respons status serta payload struktur minimal.
  • Log dan metrics: pastikan log error tidak meningkat drastis dan metrik latensi/throughput berada dalam rentang wajar.

Checklist ini dipetakan ke dalam automation plan, misalnya sebagian berjalan nightly, sebagian triggered oleh PR merge.

2. Identifikasi Flaky Test di Context Go Fiber

Flaky test sering muncul karena race condition, dependensi luar (DB, queue), atau urutan asynchronous. Untuk API Go Fiber:

  1. Segmentasikan test berdasarkan level isolasi: pisahkan unit (handler logic) dari integrasi (HTTP + DB). Flake lebih mungkin muncul di integrasi.
  2. Gunakan fixture environment representative: contohnya PostgreSQL ephemeral container; hindari shared DB yang dibersihkan manual karena menyisakan state.
  3. Catat hasil berulang: jika sebuah test gagal 2 dari 5 run berurutan di pipeline, tandai untuk investigasi; flake sering muncul ketika waktu response berubah-ubah.
  4. Gunakan retry terkontrol: di pipeline CI, jalankan kembali test yang gagal sekali sebelum menandainya sebagai regression, tetapi catat sebagai flake untuk koreksi.

Contoh pendekatan: jalankan curl terhadap handler Fiber dua kali dengan body serupa, bandingkan struktur respons. Jika satu kali sukses, sekali timeout, catat sebagai flaky akibat network atau timeout handler pada dependencies.

Contoh Test Go Fiber

func TestCreateInvoice(t *testing.T) {
	tapp := fiber.New()
	SetupRoutes(tapp)
	resp, err := tapp.Test(httptest.NewRequest("POST", "/api/invoice", strings.NewReader(`{"amount":1200}`)))
	require.NoError(t, err)
	assert.Equal(t, fiber.StatusCreated, resp.StatusCode)
	// Tambahkan cek payload dan header untuk memastikan tidak ada flake karena serialisasi
}

Pastikan test menggunakan context timeout agar tidak menunggu terlalu lama saat terjadi deadlock. Jangan men-charge database secara paralel tanpa locking karena bisa malah menyebabkan flaky behavior.

3. Pendekatan Regression API Berbasis Risiko

Bukan semua endpoint memiliki dampak yang sama. Prioritaskan regresi berdasarkan risiko bisnis/technical:

  • Endpoint kritis: auth, pembayaran, webhook; letakkan di subset regression protection dengan coverage paling tinggi.
  • Integrasi ke layanan luar: jika API Go Fiber memanggil microservice lain, pastikan contract (status code, response) tetap konsisten.
  • Perubahan schema: jika handler menerima payload baru, update test sesuai schema untuk memastikan validasi tidak regress.

Untuk mengeksekusi regression berbasis risiko, buat matrix seperti:

  • Critical endpoint > run nightly + pada PR
  • Non-critical > run nightly
  • Schema change > jalankan contract test khusus

Gunakan label (misalnya @regression) di test suite agar pipeline tahu tes mana yang harus dijalankan saat ada perubahan tertentu.

4. Integrasi Checklist ke Workflow CI/CD

Langkah praktis mengintegrasikan verifikasi ke pipeline GitHub Actions/GitLab CI:

  1. Stage seperated: Pipeline punya stage flaky-watch dan regression-check. Flaky watch menjalankan ulang test tanpa menghambat PR tapi merekam statistik.
  2. Pre-merge gating: Block merge jika regression-critical test gagal lebih dari threshold yang sudah disepakati.
  3. Artifact Test Report: Simpan laporan test (JUnit) untuk referral ketika diagnosis flake/regression.
  4. Fail fast + retry bounded: Jika satu test gagal di stage regression, pipeline bisa retry tertentu (misal up to 2 kali) untuk menyingkirkan noise lingkungan.

Contoh implementasi di GitHub Actions:

jobs:
  regression:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Go
        uses: actions/setup-go@v4
        with:
          go-version: '1.21'
      - name: Run regression suite
        run: go test ./api/... -run Regression

Tambahkan step kedua untuk rerun test tertentu jika failure terdeteksi agar flake tidak segera memblok merge.

5. Metrik Deteksi Dini dan Penanganan False Positive

Beberapa indikator membantu mendeteksi regresi:

  • Error rate (4xx/5xx) pada endpoint yang diuji; lonjakan di atas baseline menunjukkan kemungkinan regression.
  • Latency p95/p99 untuk handler Go Fiber; penambahan signifikan sering jadi indikator perubahan logic atau resource constraint baru.
  • Success ratio pada test suite repeat-run; contoh: jika 98% run lancar namun 2% gagal berulang, ada indikasi flake.

Untuk menghindari false positive akibat lingkungan:

  • Buat health check khusus pipeline: periksa koneksi DB, availability queue, dan punya fallback timeout.
  • Isi data uji (test fixture) yang deterministik agar hasil tidak bergantung pada state dunia nyata.
  • Catat nilai variabel lingkungan (region, release channel) dan klausa cabang untuk memisahkan failure environment-sensitif.

Jika false positive tetap muncul, koordinasikan pengamatan bersama tim DevOps—misal: container registry lambat, network kubernetes bermasalah—tulis peringatan di ticket release untuk menghindari panic.

Kesimpulan

Checklist verifikasi flaky test dan regression untuk API Go Fiber harus mencakup identifikasi test tidak stabil, pendekatan prioritasi regresi berbasis risiko, dan integrasi ke pipeline CI/CD dengan metrik pendeteksi dini plus strategi menangani false positive. Dengan struktur yang jelas dan automasi yang disiplin, tim bisa menurunkan noise sekaligus menjaga kualitas rilis secara konsisten.