Nuxt.js regression testing harus memberikan keyakinan bahwa perubahan kode tidak merusak rendering SSR yang mengandalkan data dinamis. Pendekatan ini dimulai dengan memisahkan kontribusi SSR versus hydration dan melengkapi setiap perubahan dengan suite kombinasi unit, integration, serta end-to-end sehingga regresi tertangkap sebelum rilis.

Menentukan Scope Regression Testing untuk Komponen SSR

Tim perlu memetakan bagian komponen yang mengeksekusi logika SSR, seperti pemanggilan API server-side, penyesuaian state awal, atau transformasi data sebelum dikirim ke hydration. Fokus pertama adalah menjaga agar server-rendered markup tetap konsisten: tiap perbedaan HTML atau data awal bisa menyebabkan rehydration errors.

Memetakan garis batas SSR vs Hydration

Pisahkan pengujian menjadi dua area. Di sisi SSR, fokuskan pada helper yang mengumpulkan data (nuxtServerInit, fetch, asyncData). Pastikan setiap helper memiliki rentang input yang jelas. Di sisi hydration, sertakan pengujian terhadap behavior interaktif tanpa mengandalkan SSR lagi, misalnya melalui unit/component test yang memuat state awal hasil fetch.

Prinsipnya, perubahan yang hanya memengaruhi hydration tidak boleh memecah markup awal. Demikian pula, perubahan SSR harus bisa diprediksi melalui snapshot atau struktur data yang deterministik.

Menggabungkan Unit, Integration, dan E2E

Untuk menutup celah regresi, kombinasikan lapisan testing berikut:

  • Unit test: sederhana dan cepat, memverifikasi fungsi utilitas SSR, seperti transformasi response API. Alat seperti Vitest atau Jest cocok.
  • Integration test: tibat terutama pada komponen Nuxt dengan asyncData dan plugins. Jalankan di lingkungan node yang berisi Nuxt server wawasan minimal (misalnya nuxt-test-utils) dan pastikan fetch hook memberikan data yang sudah dimocked.
  • End-to-end test: gunakan Playwright atau Cypress untuk memverifikasi SSR + hydration secara utuh. Jalankan dari build production atau staging untuk mendeteksi perbedaan HTML.

Setiap lapisan punya trade-off. Unit test cepat tapi tidak menangkap perbedaan markup, sementara E2E mahal tapi menutup leak terakhir. Gabungkan dengan regression suite yang dijalankan secara selektif sesuai perubahan.

Fixtures dan Mocking untuk Data Dinamis

Data SSR sering berasal dari API luar yang membuat test menjadi flaky. Gunakan Fixtures untuk data tetap yang mewakili kasus nyata (misalnya response API dengan struktur lengkap). Mocking dilakukan pada level fetch/axios agar komponen menerima data stabil.

import { mount } from '@vue/test-utils'
import MyPage from '@/pages/index.vue'

test('render SSR data from fixture', async () => {
  const fetchMock = jest.fn().mockResolvedValue({
    posts: require('@/tests/fixtures/posts.json')
  })

  const wrapper = mount(MyPage, {
    global: {
      mocks: {
        $fetch: fetchMock
      }
    }
  })

  await wrapper.vm.$nextTick()
  expect(wrapper.text()).toContain('Judul Post Pertama')
})

Fixtures membantu tetap deterministik saat objek data besar. Mocking $fetch/$axios memastikan SSR scenario tidak bergantung pada jaringan luar dan dapat dijalankan berulang kali.

Prioritas Regresi dan Integrasi CI/CD

Susun matrix prioritas regresi berdasarkan kompleksitas SSR dan jumlah pengguna. Misalnya, komponen hero yang selalu dirender di halaman utama harus diuji pada level integration dan E2E, sedangkan komponen sidebar terpinggir bisa cukup dites via unit.

Integrasikan regression suite ke pipeline CI/CD: jalankan unit/integration pada setiap commit, dan jalankan E2E hanya saat branch merge ke staging atau release. Tambahkan gate untuk memeriksa perbedaan SSR snapshot jika markup berubah.

Workflow umum:

  1. Lint + unit test saat PR dibuat.
  2. Integration tests untuk pages/komponen yang terpengaruh dengan fixtures yang relevan.
  3. E2E untuk rilis: jalankan staging build, ambil screenshot SSR, bandingkan dengan baseline.

Tambahkan alert/feedback cepat ketika regression suite gagal agar developer dapat memperbaiki sebelum merge. Dokumentasikan cara memperbarui fixtures atau snapshot untuk mencegah false-positive.

Langkah Preventif Lain

Sertakan strategi berikut untuk menyusun workflow reliabilitas:

  • Review perubahaan asyncData: setiap perubahan harus memeriksa sisi error handling, fallback data, dan struktur response.
  • Snapshot SSR: gunakan snapshot HTML untuk halaman utama dengan mock data tetap, dan jadwalkan pembaruan snapshot berbarengan dengan fitur baru.
  • Monitoring pasca-rilis: pantau logs Nuxt SSR untuk error hydration dan bandingkan param response dengan fixture.

Dengan kombinasi tersebut, tim mendapatkan cakupan regresi yang sistematis, mendeteksi flaky test lebih dini, dan menjaga keandalan komponen SSR Nuxt.js saat rilis.