Server

Run the server tests: the full application stack, including the database.

Syntax

$ vela test:server
$ vela test:server pets

Each run:

  • Creates a throwaway PocketBase database in test-data, with all migrations applied
  • Loads seeds, then fixtures, into it
  • Starts a Vite server with the page components stubbed out
  • Runs Vitest against it
  • Tears the database down again afterwards

A bare positional argument filters which tests run, and any other arguments are passed straight through to Vitest. The command exits non-zero when a test fails, so it can gate CI.

With no filter of your own, a project that has no server tests yet passes — the state a project is in right after vela enable backend. A filter that matches no test file still fails.

Test files

Server tests match src/**/*.{test,spec}.{js,ts} and run in the Vitest project named server. Component tests — *.svelte.test.ts — are excluded. The generators write a server.test.ts next to the routes they create, and a <name>.server.test.ts next to each workflow; a workflow test starts a worker in the test process, so the run completes there. vela generate form and vela enable ai only write theirs when the project has supertest installed.

Test context

test/setup.ts gives every test a fresh user and a set of clients, so tests read as HTTP requests against the running app. vela enable backend creates it, and the vitest.config.ts that loads it, in a project that has neither:

  • request - A supertest client, unauthenticated
  • agent - A supertest agent that keeps cookies, with authenticateUser()
  • admin - The PocketBase admin client
  • pb - The PocketBase client scoped to the test user
  • user - The user record created for this test

Frontend

Page, layout and error components are replaced with stubs for the duration of the run. Server tests are only concerned with the backend and the database, and skipping the frontend bundle is a large speed win.

Seeds and fixtures

The test database is not empty. After the migrations, every file in data/seeds is loaded, then every file in data/fixtures, through the same server the tests talk to — so the app’s hooks apply to these records as they would to any write. A record the current schema rejects stops the run and is named in the error; vela fixtures regen rewrites the fixtures from the schema.

Test files run in parallel against one database, so treat seeds and fixtures as a read-only baseline: read them and look records up by id, but create your own records for anything a test changes or deletes. The generated tests already work this way.