"How do you test a Nuxt application" is a question about judgement: which tests give confidence for their cost, where the seams are, what to mock and what never to mock. The toolchain in 2026 is settled: Vitest 5 (released 3 September 2026) with @nuxt/test-utils 4 for unit and component tests in a Nuxt runtime environment, and Playwright for end-to-end. What separates candidates is the strategy.

Know

• Confidence per cost. Unit tests are cheap and fast but prove little about integration; end-to-end tests prove the product works but are slow and flaky; component and integration tests in the middle give the best return for UI code. The "testing trophy" (mostly integration, some unit for logic, few end-to-end for critical flows, static analysis underneath) fits a Nuxt app better than the classic pyramid.
• Test behaviour, not implementation. Component tests interact through the accessible interface (roles, labels, text) and assert on rendered output and emitted events; they do not reach into wrapper.vm or assert on internal state. Refactors should not break tests.
• Mock at boundaries, not inside. Network through registerEndpoint or MSW, time through fake timers, the Nuxt context through mockNuxtImport; never mock the module you are testing or its siblings. If a unit test needs five mocks, the code needs a seam.
• Static analysis is a test tier: nuxt typecheck, ESLint with type-aware rules and vue-tsc catch a class of bugs no runtime test finds, for free on every commit.
• Environments: pure logic runs in Node; components and composables that use auto-imports and Nuxt plugins run in the nuxt Vitest environment with happy-dom or jsdom; visual and browser-API-heavy components can run in Vitest browser mode (Playwright provider); user flows run in Playwright against a built app.
• Flakiness is a defect. Fix the root cause (a missing await, a race on hydration, a test depending on order), quarantine with an owner and a deadline if you cannot fix it now, and never let retries hide a real race in production code.
• Nuxt specifics: SSR means a test can render on the server ($fetch('/') in e2e) and in the browser; hydration errors are testable (listen for console warnings); useAsyncData needs the Nuxt environment or registerEndpoint; stores need createTestingPinia; data fetching in setup needs mountSuspended, which handles Suspense.

How the pages fit

How it works

The strategy for one feature, "add to cart", across the levels:

Static:      nuxt typecheck + eslint            -> the CartItem type, the emitted payloads, floating promises
Unit:        cart totals, coupon rules           -> pure functions in shared/, dozens of cases in ms
Store:       useCartStore add/remove/checkout    -> createTestingPinia + registerEndpoint for /api/orders
Component:   <CartSummary>, <AddToCartButton>    -> mountSuspended, getByRole, emitted events, a11y roles
API:         POST /api/orders                    -> validation 400s, auth 401, happy path against a test DB
E2E (few):   browse -> add -> checkout           -> Playwright against the built app, one browser, storageState for login
Ops:         Lighthouse budget, axe wcag22aa     -> in CI on the preview deployment

import { defineConfig } from 'vitest/config'
import { defineVitestProject } from '@nuxt/test-utils/config'

export default defineConfig({
  test: {
    projects: [
      { test: { name: 'unit', include: ['test/unit/**/*.spec.ts'], environment: 'node' } },
      await defineVitestProject({
        test: {
          name: 'nuxt',
          include: ['test/nuxt/**/*.spec.ts'],
          environment: 'nuxt',
          environmentOptions: { nuxt: { domEnvironment: 'happy-dom', mock: { intersectionObserver: true } } },
        },
      }),
    ],
    coverage: { provider: 'v8', include: ['app/**', 'shared/**', 'server/**'], thresholds: { statements: 70 } },
  },
})

Exercise

Be able to say