Regression test otomatis menjadi jantung menjaga kestabilan API Go Fiber saat tim menambahkan fitur atau memperbaiki bug. Untuk menjawab kebutuhan ini kita perlu lebih dari sekadar menjalankan go test: strategi yang tepat meminimalkan flaky test, memastikan isolasi dependensi, dan menyediakan verifikasi berlapis setelah deployment.

Artikel ini membahas bagaimana menyusun suite regression yang terstruktur, memilih teknik isolasi dan test double, mengikatnya ke pipeline CI/CD, memantau coverage regresi, serta memberikan pola verifikasi dan penanganan false positive/negative yang praktis.

1. Struktur Suite Regression yang Terbagi Jelas

Mulai dengan membagi suite regression menjadi kelas kepentingan: core (endpoints utama), integration (interaksi storage/queue), dan contract (eksternal API). Struktur folder dapat mencerminkan lapisan ini:

regression/
  core/
    handlers_test.go
  integration/
    db_integration_test.go
  contract/
    third_party_contract_test.go
  suites.go

File suites.go memuat helper untuk setup/teardown yang sama digunakan semua suite. Penting untuk menetapkan nama subtest dengan tag deterministik sehingga mudah memfilter di pipeline CI.

Gunakan tabel test di setiap file untuk memastikan setiap skenario dinyatakan eksplisit, misalnya memeriksa respons JSON dan header. Tidak hanya memanggil handler, tapi juga memverifikasi side effect dengan mocking atau menggunakan database in-memory.

2. Teknik Isolasi dan Test Double

Regression yang dapat dipercaya harus menghilangkan ketergantungan pada layanan eksternal nyata. Pendekatan yang efektif:

  • Mock server internal dengan httptest.NewServer untuk API downstream. Pastikan respons dikontrol agar selalu sama, dan jangan mengandalkan jaringan nyata.
  • Interface wrapper untuk database atau queue seperti NATS/RabbitMQ, lalu implementasikan mock menggunakan gomock atau manual stub.
  • Test double dengan callback yang mencatat panggilan, sehingga regression bisa memastikan event yang dihasilkan sesuai kontrak.

Contoh pengaturan mock untuk service sederhana:

type UserStore interface {
    GetUser(ctx context.Context, id string) (*User, error)
}

func TestUserHandler(t *testing.T) {
    ctrl := gomock.NewController(t)
    defer ctrl.Finish()

    mockStore := NewMockUserStore(ctrl)
    mockStore.EXPECT().GetUser(gomock.Any(), "123").Return(&User{ID: "123", Name: "test"}, nil)

    app := fiber.New()
    app.Get("/users/:id", func(c *fiber.Ctx) error {
        usr, err := mockStore.GetUser(c.Context(), c.Params("id"))
        if err != nil {
            return c.Status(fiber.StatusInternalServerError).SendString("error")
        }
        return c.JSON(usr)
    })

    req := httptest.NewRequest("GET", "/users/123", nil)
    resp, _ := app.Test(req)
    if resp.StatusCode != fiber.StatusOK {
        t.Fatalf("expected 200, got %d", resp.StatusCode)
    }
}

Mock ini menjamin regresi tidak tergantung data nyata dan mencegah flaky test karena perubahan state yang tidak terkelola.

3. Integrasi Regression ke Pipeline CI/CD

Regression testing sebaiknya dijalankan di pipeline CI sebagai gate sebelum deploy. Langkah ideal:

  1. Jalankan go test ./... -coverprofile=coverage.out lalu parse coverage untuk regression-critical package.
  2. Gunakan tool seperti gotestsum untuk output yang mudah dibaca dan waktu eksekusi per file.
  3. Tetapkan threshold coverage untuk paket regression dengan go tool cover -func=coverage.out dan gagal pipeline jika critical coverage turun.
  4. Jika ada environment staging, spin regression suite di sana menggunakan container yang mereplikasi produksi dengan varian konfigurasi (misalnya connection pool). Outputting logs ke /logs/regression membantu debugging.

Pipeline juga harus mengelompokkan regression berdasarkan waktu: run cepat (core) di setiap commit, dan suite lengkap (termasuk integration/contract) hanya di merge ke main.

4. Monitoring Coverage dan Regression Trend

Coverage regression membantu memastikan kode kritis tetap diuji. Terapkan monitoring dengan langkah-langkah berikut:

  • Simak persentase coverage per paket secara historis dan kirim alert jika turun lebih dari 1-2% di area regression.
  • Simpan coverage.out dalam artifact pipeline dan gabungkan dengan dashboard coverage seperti Codecov atau SonarQube agar bisa dibandingkan antar-commit.
  • Jangan hanya mengandalkan coverage persentase: lebih baik menulis skenario yang memverifikasi side effect penting (misalnya queue publication) daripada menaikkan coverage dengan assert tidak bermakna.

Perhatikan bahwa coverage tinggi tidak selalu berarti regression-free; pastikan assertion test memvalidasi behavior nyata.

5. Menghindari False Positive dan False Negative

False positive (gagal padahal tidak ada bug) dan false negative (lolos walau ada bug) mengikis kepercayaan terhadap regression suite. Beberapa praktik yang membantu:

  • Gunakan retry terbatas hanya untuk interaksi network non-deterministik. Jika test terus gagal walau sudah retry, laporkan sebagai bug.
  • Batasi penggunaan waktu tunggu global; lebih baik menggunakan context.WithTimeout untuk request tertentu sehingga regression tidak hang ketika service downstream tidak merespons.
  • Tambahkan log dan assertion error message yang mudah dipahami; ketika test gagal, engineer tahu apakah karena input tidak valid atau async operation belum selesai.

Jika false negative diketahui (bug baru tidak ters caught), evaluasi apakah test perlu menambah assertion, memperpanjang timeout, atau replika lingkungan yang lebih mirip produksi.

6. Verifikasi Pasca-Deploy

Regression tidak berhenti saat pipeline hijau. Strategi verifikasi setelah deploy membantu memastikan versi yang dirilis tetap stabil:

  • Smoke regression berupa subset core tests dijalankan otomatis di environment staging atau production baru.
  • Gunakan health check endpoint di Go Fiber untuk memverifikasi database connectivity dan queue status. Endpoint ini diuji melalui regression suite.
  • Integrasikan canary release dengan regression suite yang memverifikasi behavior sebelum traffic dialihkan sepenuhnya.

Setelah deploy, pantau metrik latency dan error rate yang dapat dicatat oleh middleware Fiber. Hubungkan alert dengan hasil regression agar tim segera bereaksi bila ada regresi baru.

7. Rekomendasi Tooling Populer

Tool berikut mendukung strategi regression Go Fiber:

  • Go test sebagai dasar; kombinasikan dengan testify/assert untuk assertion lebih ekspresif.
  • gomock atau mockery untuk membuat mock interface, memastikan isolasi dependensi.
  • Testcontainers (atau dockertest) untuk menjalankan database/Redis lokal secara deterministik saat regression memerlukan state nyata.
  • gotestsum untuk output test runner yang konsisten di CI dengan --format=short atau --format=standard-verbose.
  • Pipeline CI seperti GitHub Actions, GitLab CI, atau Jenkins yang menjalankan regression suite dan menyimpan artifact log/coverage.

Pilih tooling berdasarkan kebutuhan tim: jika depended on multi-service, pertimbangkan testcontainers; jika tim kecil, mocking manual cukup dengan go test.

Kesimpulan

Regression testing otomatis di Go Fiber tidak hanya soal mengeksekusi go test, tapi juga merancang suite yang tersegmentasi, menjaga isolasi dependensi, dan mengintegrasikan hasilnya ke pipeline serta monitoring pasca-deploy. Dengan struktur yang jelas, teknik test double yang rapi, dan landasan CI/CD yang kuat, tim menjaga API tetap stabil meski terjerat perubahan.