# Write Vitest Tests for Nuxt Server Routes

Yes. An agent adds @nuxt/test-utils and Vitest coverage for server routes and composables, stubs TMDB at the network edge, and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/write-nuxt-tests/nuxt/), in a Project that has your repository.

## What the agent does

The agent reads how the Nuxt Movies app talks to TMDB. In nuxt/movies, the Nuxt app's `server/api/index.ts` is a tiny `defineEventHandler` returning `Nuxt Movies API`, while real HTTP proxying lives in the nested `proxy/` Nitro app: `proxy/routes/tmdb/[...path].ts` forwards to `https://api.themoviedb.org/3` with `runtimeConfig.tmdb.apiKey`, and `proxy/routes/ipx/[...path].ts` fronts image.tmdb.org. Client composables in `app/composables/tmdb.ts` call `$fetch` against `https://movies-proxy.vercel.app/tmdb` (overridable via `runtimeConfig.public.apiBaseUrl` in `nuxt.config.ts`).

`package.json` pins pnpm `11.1.2` and Node `^24`, with scripts `test:unit` → `vitest` and `@nuxt/test-utils` `^4.2.0`. `vitest.config.ts` uses `defineVitestConfig` from `@nuxt/test-utils/config` and includes `tests/unit/**`, `components/**/*.test.ts` and `composables/**/*.test.ts`. Composables such as `item.ts` already have `item.nuxt.test.ts`; `tmdb.ts` list/fetch helpers and the Nitro `proxy/routes/tmdb` handler have little direct coverage.

New tests use the Nuxt environment from `@nuxt/test-utils`: Vitest cases for `fetchTMDB` / `listMedia` that stub `$fetch` or the network at the boundary (no live TMDB key), and Nitro route tests for `proxy/routes/tmdb/[...path].ts` that assert query forwarding and the missing-API-key error. It does not hit api.themoviedb.org and does not commit secrets.

It runs `pnpm test:unit` (installing with the lockfile's pnpm version), fixes Nuxt environment setup issues, and opens a pull request adding tests under `app/composables/`, `tests/unit/` and/or `proxy/` as appropriate. It also checks `vitest.config.ts` coverage includes and the existing `app/composables/item.nuxt.test.ts` style (Vitest `describe`/`it`, `#shared/types`, mocks from `tests/unit/mocks`) so new TMDB tests sit next to the Movies team's patterns rather than inventing a second runner. For the proxy package it reads `proxy/nitro.config.ts` route rules for `/tmdb/**` and the `tmdb.apiKey` runtime config key before asserting the handler in `proxy/routes/tmdb/[...path].ts`.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Write tests with @nuxt/test-utils and Vitest for this Nuxt app's server API routes and composables, stubbing only the external TMDB HTTP calls at the network boundary. Run them and open a pull request.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-nuxt-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request with new Vitest / `@nuxt/test-utils` files covering TMDB composables and the Nitro TMDB proxy route, plus any small test helpers under `tests/unit/mocks`. Application runtime config defaults stay non-secret; no `.env` with a real `TMDB_API_KEY` is added.

The pull request description names `pnpm test:unit` as the command that passed and which modules each file covers. The trajectory includes Vitest output and shows that outbound TMDB calls were stubbed.

Before merging, a reviewer checks that stubs sit at `$fetch` / Nitro `$fetch` boundaries rather than rewriting `tmdb.ts` production logic, that `vitest.config.ts` include globs pick up the new files, and that e2e Playwright jobs remain separate.

## Run it on every composable or proxy route changed

When pulls touch `app/composables/tmdb.ts` or `proxy/routes/**`, POST this session request so unit coverage tracks the TMDB boundary without needing a TMDB key in CI secrets for this job.

Deliver `run.completed` to your frontend channel via the API key webhook. Parallel Nuxt apps can share the API key up to `max_concurrent`.

## Why run it on Rush?

Nuxt test-utils boots a Nuxt environment and may build Nitro routes; that is slow and noisy on a laptop beside `nuxt dev`. Rush runs `pnpm test:unit` in a clean sandbox with Node 24 and pnpm 11 matching `devEngines`, so local servers keep running. Component fixtures already in the repo (for example person Card tests that assert `/tmdb` image URLs) show the team cares about TMDB URL shape; the new suite extends that idea to the fetch and proxy layers.

Stubbing only the TMDB HTTP edge keeps tests honest about query shaping and error handling without flaking on the public API. The pull request plus trajectory are the proof reviewers re-run with the same Vitest config.

## Frequently asked questions

### Do I need a TMDB API key for this job?

No. The agent stubs outbound HTTP at the network boundary. Keys stay out of the repository; the proxy's missing-key error path is tested with an empty `runtimeConfig.tmdb.apiKey`.

### Are Playwright e2e tests in scope?

No. This page is the Vitest / `@nuxt/test-utils` unit layer (`pnpm test:unit`). E2E remains `pnpm test:e2e` unless you ask for that separately.

### Which package manager does it use?

pnpm, per `pnpm-lock.yaml` and `devEngines.packageManager` version `11.1.2` in the Movies app. It does not switch the repo to npm.

### What about the root server/api/index.ts?

It can get a one-liner assertion, but the meaningful server routes for TMDB are under `proxy/routes/`. The agent spends most of the suite there and on `app/composables/tmdb.ts`.