Strategi uji integrasi Go Fiber harus langsung menjawab dua tekanan utama: memastikan API bekerja end-to-end dan mendeteksi kegagalan non-deterministik sebelum masuk pipeline produksi. Artikel ini membahas bagaimana membangun workflow verifikasi yang reliable, mengelola data uji yang deterministik, dan menghadirkan mekanisme observasi plus kebijakan regresi yang praktis untuk Go Fiber.

Dengan pendekatan ini, tim dapat menyaring flaky test lebih awal, menjaga coverage kritis, dan membuat regression pipeline tetap sehat tanpa menambah overhead manual.

1. Tata Alur Verifikasi Uji Integrasi

Bisnis logic Go Fiber diuji dengan memutarkan request melalui handler, middleware, dan penyimpanan data. Workflow verifikasi yang aman terdiri dari tiga langkah: 1) setup deterministik, 2) eksekusi request end-to-end, dan 3) validasi hasil serta cleanup. Diperlukan environment yang dapat dibuat ulang secara otomatis setiap kali run agar hasil konsisten.

Alur tipikal:

  1. Inisialisasi server Fiber dengan route yang bertumpu pada mockable layer (misalnya repository atau client HTTP eksternal). Pastikan dependency injection sedari awal agar versi production handler tetap dipakai.
  2. Persiapan data dan dependency (lihat bagian berikut).
  3. Eksekusi HTTP request menggunakan httptest.NewRequest dan router Fiber yang dijalankan dalam mode test.
  4. Verifikasi state baik dari HTTP response maupun database side effects.
  5. Cleanup/rollback untuk menghindari sisa data yang memengaruhi run berikutnya.

Gunakan helper seperti TestServer yang menerapkan context cancel agar server tidak menumpuk goroutine antara test.

2. Pengelolaan Data Tes dan Environment

Agar uji integrasi Go Fiber dapat diulang, data tes harus dikontrol. Cara umum:

  • Database terisolasi: jalankan container DB (Postgres/MySQL) per pipeline stage. Untuk local, gunakan Docker Compose; di CI, gunakan service container. Tidak perlu versi spesifik dalam artikel ini, tetapi sesuaikan dengan image resmi.
  • Migrasi otomatis: jalankan migrasi schema pendek setelah container siap (misalnya via Goose atau migrasi manual). Pastikan migrasi hanya dilakukan sekali per run agar tidak memblokir.
  • Data fixture: isi data menggunakan seed script yang deterministik (insert dengan nilai tetap) atau gunakan transaction rollback per test. Teknik preferensial adalah memulai transaction dan rollback di akhir, sehingga DB tetap bersih tanpa drop schema.
  • Mock dependency eksternal: ganti outbound HTTP client dengan stub yang mengembalikan response statis. Tools seperti httptest.Server berguna untuk menahan permintaan keluar. Pastikan mock hanya aktif di context test.

Berikut snippet setup sederhana:

func setupTestServer(t *testing.T) (*fiber.App, func()) {
    db := mustConnectTestDB(t)
    cleanup := func() {
        db.Exec("TRUNCATE TABLE users CASCADE")
        db.Close()
    }
    app := fiber.New()
    app.Use(authMiddleware(db))
    registerRoutes(app, db)
    return app, cleanup
}

Penting memastikan cleanup dijalankan walaupun terjadi panic. Gunakan t.Cleanup agar rutin dijalankan otomatis.

3. Mencegah dan Mendeteksi Flaky Test

Flaky test sangat merusak kepercayaan terhadap pipeline. Strategi deteksi dan preventif:

  • Pengulangan selektif: jalankan subset uji integrasi krusial dua kali secara lokal atau di pipeline. Jika hasil berbeda, log tambahan diaktifkan untuk melihat state.
  • Atur timeout eksplisit saat memanggil Fiber app atau DB. Timeout default membuat test tak terkendalikan ketika dependency deadlock.
  • Gunakan deterministic seed pada data acak agar setiap run memiliki input yang sama. Hindari dependency ke waktu nyata (time.Now) tanpa injeksi waktu yang dapat dikendalikan.
  • Bersihkan goroutine dengan context.WithTimeout dan pastikan worker tidak menunggu channel yang tidak pernah ditutup.
  • Catat log dengan trace ID untuk setiap request. Gunakan middleware log Fiber untuk menampilkan request ID dan status. Jika test gagal secara sporadis, trace ID membantu melacak dependency mana yang memicu.

Contoh strategi pengulangan otomatis di pipeline:

  • Jika uji integrasi gagal karena timeout atau status 5xx, eksekusi ulang test yang sama hingga tiga kali dengan jeda pendek.
  • Jika rerun berhasil, laporkan hasil awal sebagai flaky untuk investigasi; jika tetap gagal, laporkan sebagai regresi.

Gunakan badge atau label di hasil CI untuk menandai test flaky sehingga engineer tahu perbedaan antara false-negative vs regresi sebenarnya.

4. Observabilitas dan Menjaga Regression Pipeline Sehat

Regression pipeline harus memberikan sinyal yang dapat ditindaklanjuti:

  • Coverage kritis: Fokuskan uji integrasi pada flow yang paling mungkin mengalami regresi, misalnya autentikasi, transaksi data, dan circuit breaker. Review coverage setiap sprint dan tambahkan test jika area ini baru ditambahkan.
  • Log & tracing: Gunakan log yang mencatat header utama dan body terbatas (hindari data sensitif). Untuk tracing, integrasikan context trace seperti OpenTelemetry agar distribusi trace dapat dianalisis. Ini membantu memetakan cause regression saat terjadi heat.
  • Review hasil non-deterministik: Jika pipeline mendeteksi nilai response yang berbeda antar run, tandai sebagai flaky. Dokumenkan penyebab (misalnya race condition di repository). Silakan review tim jika test harus direvisi.
  • Retri otomatis berbasis deteksi flaky: Jika pipeline mendeteksi kegagalan yang sebelumnya pernah ditandai sebagai flaky, lakukan retrigger. Jika retrigger berhasil konsisten, mungkin test perlu diperbaiki.
  • Kunci dependency versi: Pastikan dependency Fiber, ORM, DB client, dll. dikunci versi agar perubahan transitive tidak memicu regresi tanpa disadari.

Debugging tips:

  • Gunakan go test -run TestName -count=10 untuk mencari flaky secara lokal.
  • Tabulasi hasil DB dan response di log untuk mengetahui kondisi sebelum failure.
  • Jaga agar pipeline mencetak trace ID dan span identity; ini memudahkan korelasi antara log dan tracing dashboard.

Dengan workflow yang konsisten, data uji yang dapat direproduksi, serta observabilitas yang baik, tim dapat mendeteksi flaky test lebih cepat sekaligus menjaga pipeline regresi tetap sehat tanpa terlalu banyak alert palsu.