Regresi dan flaky test terus menghadang tim Laravel yang memperbesar fitur. Workflow verifikasi multi-layer Laravel menjawab masalah ini dengan menempatkan lapisan verifikasi yang saling melengkapi: unit test untuk logika tersendiri, feature test untuk endpoint dan aksi, serta end-to-end test untuk alur bisnis lengkap. Pendekatan ini memetakan titik risiko, sehingga ketika satu lapisan gagal, tim langsung tahu area mitigasinya.

Panduan ini menguraikan praktik praktis menyusun kombinasi tes tersebut, menyeimbangkan data environment, dan menambahkan gate CI yang memastikan migrasi, factory, serta seed selaras. Pembaca juga akan menemukan cara memastikan kontrak test dapat diulang, menangani rollback cepat saat verifikasi gagal, serta indikator kapan menambahkan regression suite baru.

Menyusun Kombinasi Unit, Feature, dan End-to-End Test

Setiap jenis test punya target berbeda, jadi jangan mengganti satu lapisan dengan yang lain. Unit test ideal untuk layanan, helper, dan policy, karena ia memeriksa satu kelas tanpa dependensi dari HTTP atau database besar. Gunakan dependency injection dan mocking (misalnya Mockery atau fake) agar unit test tetap ringan dan deterministik.

Feature test memvalidasi perilaku endpoint, middleware, dan event secara keseluruhan. Kuncinya: data setup harus konsisten dan mencerminkan contract antara penerima dan yang dipanggil. Contoh sederhana:

public function test_pengguna_default_mendapatkan_role_user_setelah_register()
{
    $this->postJson('/register', [
        'name' => 'Budi',
        'email' => '[email protected]',
        'password' => 'rahasia123',
        'password_confirmation' => 'rahasia123',
    ])->assertCreated()
      ->assertJsonStructure(['id', 'email', 'roles']);

    $this->assertDatabaseHas('roles', [
        'name' => 'user',
    ]);
}

Perhatikan kombinasi assertJsonStructure dan assertDatabaseHas: ini menyatakan kontrak API sekaligus validasi metadata data.

End-to-end test (misalnya menggunakan Laravel Dusk atau Cypress jika front-end terlibat) menutup celah integrasi antar modul. Fokus di sini bukan sebanyak jumlah assertion, tetapi memastikan alur inti—misal "registrasi → verifikasi email → akses dasbor"—berjalan dari frontend ke backend. Pastikan end-to-end test dijalankan dengan database yang dekat seperti staging kecil agar hasil mendekati produksi.

Menjaga Data Environment dan Kontrak Test yang Bisa Diulang

Data lingkungan harus stabil agar tes reproducible. Gunakan RefreshDatabase untuk memulai dari migrasi bersih, atau jika perlu jumlah tabel besar, pakai transaction-based dengan DatabaseTransactions. Untuk environment yang memerlukan data tertentu, siapkan seed minimal yang sama untuk local, CI, dan staging.

Kontrak test membantu tim mengecek bahwa pola data tetap konsisten. Misalnya, buat trait helper untuk menyusun payload standar dan gunakan kembali di beberapa test:

trait RegistersUserContract
{
    protected function registerPayload(): array
    {
        return [
            'name' => 'Budi',
            'email' => '[email protected]',
            'password' => 'rahasia123',
            'password_confirmation' => 'rahasia123',
        ];
    }
}

Trait ini memastikan semua test registrasi memakai struktur data sama. Kontrak semacam ini bisa diperluas ke API response schema dan state database yang diharapkan.

Verifikasi Metadata: Migrasi, Factory, dan Seed

Regresi sering muncul karena file migrasi tidak sinkron, factory tidak lengkap, atau seed berubah tanpa lintasan yang diuji. Tambahkan langkah di workflow CI untuk:

  • Menjalankan php artisan migrate --force pada refresh environment.
  • Mensintesis factory dengan factory(App\Models\User::class)->create() untuk memastikan definisi field masih valid.
  • Menjalankan php artisan db:seed --class=DatabaseSeeder di environment uji untuk melihat apakah seed gagal karena constraint.

Langkah-langkah ini akan memverifikasi metadata yang mungkin tidak disentuh oleh single test suite. Jika seed membutuhkan data tertentu, validasi kunci unik (unique), foreign key, dan format timestamp sebagai bagian dari job CI.

Gate CI untuk Verifikasi Metadata dan Pemantauan Flaky

CI gate harus memaketkan semua verifikasi sebelum merge. Gunakan job berurutan:

  1. Pre-check: php artisan test --testsuite=Unit dengan --parallel jika tersedia.
  2. Feature + contract test.
  3. DB metadata: migrate:fresh --seed, factory smoke test, seed script.
  4. End-to-end (biasanya ditandai optional, tapi harus run di branch release/staging).

Isi job metadata dengan environment data seimbang agar sebaran data tidak membuat test flaky. Simpan log pengecualian untuk artisan migrate dan seeding sehingga jika gagal Anda bisa rollback cepat ke commit sebelumnya dan jalankan ulang dengan data yang sama.

Untuk rollback: jika gate mendeteksi kegagalan seeding atau kontrak, lakukan php artisan migrate:rollback dan validasi ulang menggunakan seed yang lebih kecil. Jangan langsung men-rollback semua karena bisa menyembunyikan masalah yang sebenarnya; catat error dan perbaiki migration/seed terlebih dahulu.

Pengumpulan Indikator Penambahan Regression Suite

Indikator kapan membuat regression suite baru meliputi:

  • Bug berulang di fitur tertentu → buat regression suite yang mengeksekusi user journey tersebut.
  • Perubahan besar pada domain model atau API → tambahkan regression suite khusus untuk kontrak lama dan baru.
  • Kombinasi data tertentu (misal multi-tenancy, timezone) yang memicu flaky test berulang → buat test data-driven yang mengeksplorasi variasi tersebut.

Regression suite harus selalu dijalankan di gate CI sebelum rilis mayor. Jika suite terlalu berat, jalankan dalam batch khusus di nightly build dengan alarm untuk modul yang gagal.

Penutup

Workflow verifikasi multi-layer Laravel tidak berhenti pada tambahan tes. Ia termasuk menjaga environment data, menjaga metadata migrasi/factory/seed, memantau flaky test, serta memberi ruang rollback ketika verifikasi gagal. Dengan indikator yang jelas untuk menambahkan regression suite baru, tim bisa menjaga kepercayaan terhadap rilis baru tanpa mengorbankan waktu debugging.