Menangani Flaky Test di CI Laravel

Flaky test sering muncul karena ketergantungan yang tidak deterministik pada status lingkungan, database, atau antrian, lalu memperlambat rilis. Strategi pengujian Laravel yang saya paparkan di sini langsung membantu menstabilkan pipeline CI dengan langkah konkret: struktur suite, isolasi dependensi, manajemen database, parallel test, serta monitoring hasil dan retry.

Dengan memprioritaskan stabilitas, tim Anda menghindari false positive/negative dan tetap bisa merilis dengan kecepatan yang sehat.

Struktur Test Suite yang Jelas

Mulailah dengan memetakan tes ke dalam kelompok yang berbeda: unit, feature/integration, dan tests yang memerlukan layanan eksternal. Contohnya:

  • Unit tests hanya menguji kode lokal tanpa database atau HTTP.
  • Feature tests menguji behavior Laravel lengkap, termasuk route dan middleware.
  • Smoke tests (opsional) memastikan endpoint penting tetap hidup setelah deploy.

Mengelompokkan tes memudahkan pengaturan pipeline: jalankan unit tests di stage awal, feature tests setelah migrasi dan seed minimal siap, lalu smoke tests di deploy.

Menentukan suite berbeda di PHPUnit

Gunakan konfigurasi phpunit.xml untuk mendefinisikan suite terpisah:

<testsuites>
    <testsuite name="unit">
        <directory suffix="Test.php">tests/Unit</directory>
    </testsuite>
    <testsuite name="feature">
        <directory suffix="Test.php">tests/Feature</directory>
    </testsuite>
</testsuites>

Memanggil php artisan test --testsuite=unit memastikan hanya tes ringan yang berjalan awal. Ini memperkecil ruang lingkup ketika flaky muncul di kelompok tertentu.

Isolasi Dependensi dan Mocking

Flaky test sering disebabkan oleh ketergantungan ke layanan eksternal. Laravel memudahkan isolasi dengan dependency injection. Hindari memanggil API nyata dalam tes: mock client atau gunakan fake service Laravel.

Contoh penggunaan fake Mail:

Mail::fake();
$post = Post::factory()->create();
PostPublished::dispatch($post);
Mail::assertSent(PostPublishedMail::class);

Dengan Mail::fake(), kita memastikan tes tidak memerlukan SMTP dan hasilnya deterministik.

Untuk dependensi lain seperti HTTP external, gunakan Http::fake() atau service class yang bisa di-bind ulang di container dengan tipe testing.

Manajemen Database dan State

Database yang tidak direset menyebabkan race dan data menumpuk, yang memicu flaky. Gunakan trait seperti RefreshDatabase untuk memastikan migrasi ulang setiap tes yang memerlukannya. Jika suite besar, pertimbangkan strategi separasi:

  • Database Transactions untuk tes unit atau ringan (trait DatabaseTransactions).
  • RefreshDatabase hanya untuk feature tests yang memerlukan migrasi penuh.

Tambahkan seed minimal yang deterministik dan hindari seed random. Jika Anda menggunakan factory, pastikan factories tidak menghasilkan data acak yang memengaruhi assertion (contoh: timestamp fixed).

Untuk menghindari migrasi lambat di CI, pertimbangkan cache schema dengan php artisan migrate:fresh --seed pada stage sendiri dan gunakan snapshot database dengan tool seperti SQLite in-memory untuk suite yang tidak memerlukan Postgres khusus.

Parallel Test dengan Kontrol Flaky

Parallel testing dapat menyingkat waktu, tapi jika belum siap, malah menambah flaky karena resource contestion. Laravel mendukung parallel test via php artisan test --parallel. Pastikan:

  • Tiap proses parallel punya database sendiri (Laravel akan membuat database berdasarkan PARALLEL_TOKEN).
  • State file atau cache tidak dibagi antar proses.
  • Gunakan php artisan test --parallel --testsuite=feature hanya jika konfigurasi database dan queue sudah isolated.

Jika flaky tetap terjadi, ubah konfigurasi menjadi limited workers atau non-parallel untuk suite tertentu.

Monitoring Hasil Tes dan Retry CI

CI harus bisa mendeteksi regressi lebih awal. Tambahkan monitoring sederhana:

  • Catat akhir log tes (passed/failed) dan warn jika suite tertentu sering gagal.
  • Gunakan alat CI yang mendukung retry otomatis untuk tes yang diketahui flaky tapi belum diperbaiki, lalu tandai sebagai to-do pada backlog.

Contoh retry: di GitHub Actions bisa menambahkan retry: 1 pada job test. Tapi jangan jadikan retry sebagai solusi permanen; gunakan untuk memberi waktu memeriksa flaky yang sedang diinvestigasi.

Debugging tip: setelah retried test masih gagal, jalankan lokal dengan php artisan test --filter atau ./vendor/bin/phpunit --filter dan periksa log serta database state.

Kesimpulan

Strategi pengujian Laravel yang efektif untuk mengendalikan flaky test meliputi pemisahan suite, isolasi dependensi, manajemen state database, parallel testing yang terkontrol, serta monitoring hasil dan retry. Komitmen terhadap struktur ini memastikan tim bisa mendeteksi regresi lebih cepat tanpa memperlambat pipeline CI.