Nuxt.js menghadapi tantangan unik saat menjalankan komponen SSR: render server yang bergantung data eksternal atau waktu sering menghasilkan flaky tests. Solusi yang efektif memerlukan strategi testing yang menggabungkan unit, integration, dan E2E, lalu memperkuatnya dengan praktik observabilitas dan workflow CI yang mampu mendeteksi serta mengisolasi kegagalan tersebut sebelum rilis.

Artikel ini menjelaskan cara menyusun fase testing untuk Nuxt 3, termasuk pola deteksi flaky SSR, pemisahan suite berdasarkan titik kegagalan, dan mekanisme verifikasi otomatis seperti snapshot server atau rekonsiliasi hasil lokal terhadap edge.

Memahami Sumber Flaky Component SSR di Nuxt 3

Flaky behavior umumnya muncul dari dependensi asynchronous di asyncData atau middleware SSR yang bergantung pada third-party API, waktu, atau state global yang sulit direplikasi. Karena Nuxt merender ulang halaman di server dan client, ketidakpastian ini bisa mengakibatkan hasil yang berbeda antara build dan runtime production. Sebelum kita membangun suite testing, identifikasi titik kegagalan dengan log yang mencatat:

  • Response time API eksternal yang lebih panjang dari rata-rata.
  • Perbedaan data antara server-side payload dan client-side hydration.
  • Render non-deterministik akibat dependensi random atau memperlakukan waktu (`Date.now`, `Math.random`).

Dengan data tersebut, kita tahu bagian mana yang harus diuji lebih ketat.

Strategi Testing Terpadu: Unit, Integration, dan E2E

Gunakan rangkaian testing berlapis:

  1. Unit tests (Vitest + Testing Library Vue) untuk mengecek komponen dan composable secara deterministik. Mock seluruh dependensi asynchronous sehingga hasil predictible.
  2. Integration tests untuk memastikan data flow dari API ke store dan komponen. Taruh mock server (misalnya msw) agar data request bisa disesuaikan dengan scenario flaky yang diduga.
  3. E2E tests (Playwright/Addressable Nuxt E2E starter kit) untuk menjalankan SSR di environment sebenar dan membandingkan snapshot render.

Contoh potongan konfigurasi Playwright yang memeriksa SSR snapshot:

import { test, expect } from '@playwright/test';
import { createServer } from 'vite';

test('SSR snapshot halaman produk', async ({ page }) => {
  await page.goto('http://localhost:3000/product/42');
  const html = await page.content();
  expect(html).toMatchSnapshot('product-42.html');
});

Snapshot ini dijalankan terhadap server Nuxt build untuk mendeteksi perubahan tak terduga. Saat tests dijalankan di CI, bandingkan snapshot terakhir dengan hasil rerun.

Observabilitas dan Pemisahan Test Suite Berdasarkan Titik Kegagalan

Observabilitas membantu mengklasifikasi flaky yang berasal dari server, client, atau data layer. Terapkan pola berikut:

  • Tracing: Gunakan span pada middleware SSR agar latency request bisa dipantau.
  • Logging terstruktur: Log event render, hydration, dan error SSR dengan metadata seperti route, user agent, dan timestamp.
  • Metrics: Catat failure rate per route dan rerun rate di CI.

Pisahkan test suite berdasar level kegagalan:

  • Suite component/unit untuk isolasi logic.
  • Suite integration menguji composable, store, dan API mocking.
  • Suite E2E SSR yang menjalankan build Nuxt, mengeksekusi render pada server, lalu membandingkan DOM dan data-lifecycle.

Dengan pemisahan ini, ketika suite E2E gagal, tim dapat langsung memeriksa apakah masalah bersifat data/API (integration) atau rendering (component/unit).

Verifikasi Otomatis Sebelum Rilis

Implementasikan langkah-langkah otomasi sebelum deployment:

  • Snapshot server: Build Nuxt dengan nuxi build dan jalankan capture HTML untuk route penting. Simpan snapshot di artefak dan jalankan referensi terhadap hasil terakhir.
  • Rekonsiliasi lokal vs edge: Jalankan build di environment lokal lalu bandingkan dengan edge preview (misalnya Nuxt Deploy Preview). Skema ini mengungkap perbedaan runtime yang hanya terjadi pada edge.
  • Stable data fixture: Gunakan data fixture khusus untuk SSR tests dan visual-diff agar hasil tidak terpengaruh API live.

Penambahan fase “pre-release verification” di CI memastikan bahwa setiap perubahan dibuktikan tidak merusak render SSR.

Metrik Stabilitas dan Workflow CI Rerun Flaky

Rekam metrik berikut untuk memantau kestabilan:

  • Failure rate per suite dan rata-rata rerun per commit.
  • Time-to-fix rerun flaky test.
  • Percents of SSR snapshot mismatch vs baseline.

Untuk CI (misalnya GitHub Actions), buat workflow yang otomatis rerun suite yang sempat gagal:

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx nuxi preview --port 3000 &
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install
      - run: npx playwright test
    continue-on-error: true
  rerun:
    needs: e2e
    if: needs.e2e.result == 'failure'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npx playwright test --retries=2

Dengan pola ini, suite E2E rerun hanya ketika gagal. Pastikan rerun juga mengumpulkan snapshot terbaru agar dapat dibandingkan dengan baseline.

Penutup

Menyusun strategi testing Nuxt.js yang menggabungkan unit, integration, dan E2E membantu mendeteksi flaky component SSR yang berpotensi merusak experience. Tambahkan observabilitas, pemisahan suite berdasarkan titik kegagalan, serta workflow CI yang mengotomatiskan rerun dan verifikasi snapshot sebelum rilis. Pendekatan ini menjaga stabilitas build ulang dan memungkinkan pengembaliannya ke kondisi aman saat regresi muncul.