Servidor

Ejecuta las pruebas de servidor: toda la pila de la aplicación, incluida la base de datos.

Sintaxis

$ vela test:server
$ vela test:server pets

Cada ejecución:

  • Crea una base de datos PocketBase desechable en test-data, con todas las migraciones aplicadas
  • Carga en ella los seeds y después los fixtures
  • Inicia un servidor de Vite con los componentes de página sustituidos por stubs
  • Ejecuta Vitest contra él
  • Desmonta la base de datos al terminar

Un argumento posicional simple filtra qué pruebas se ejecutan, y cualquier otro argumento se pasa directamente a Vitest. El comando termina con un código distinto de cero cuando falla una prueba, así que puede usarse como puerta en CI.

Sin un filtro tuyo, un proyecto que todavía no tiene pruebas de servidor pasa — el estado en que queda un proyecto justo después de vela enable backend. Un filtro que no coincide con ningún archivo de prueba sigue fallando.

Archivos de prueba

Las pruebas de servidor coinciden con src/**/*.{test,spec}.{js,ts} y se ejecutan en el proyecto de Vitest llamado server. Las pruebas de componentes — *.svelte.test.ts — quedan excluidas. Los generadores escriben un server.test.ts junto a las rutas que crean, y un <name>.server.test.ts junto a cada workflow; una prueba de workflow arranca un worker en el proceso de pruebas, así que la ejecución se completa ahí. vela generate form y vela enable ai solo escriben la suya cuando el proyecto tiene supertest instalado.

Contexto de prueba

test/setup.ts da a cada prueba un usuario nuevo y un conjunto de clientes, de modo que las pruebas se leen como peticiones HTTP contra la aplicación en ejecución. vela enable backend lo crea, junto con el vitest.config.ts que lo carga, en un proyecto que no tiene ninguno de los dos:

  • request - Un cliente de supertest, sin autenticar
  • agent - Un agente de supertest que conserva las cookies, con authenticateUser()
  • admin - El cliente de administración de PocketBase
  • pb - El cliente de PocketBase con ámbito del usuario de prueba
  • user - El registro de usuario creado para esta prueba

Frontend

Los componentes de página, layout y error se sustituyen por stubs durante la ejecución. Las pruebas de servidor solo se ocupan del backend y la base de datos, y saltarse el bundle del frontend supone una gran ganancia de velocidad.

Seeds y fixtures

La base de datos de pruebas no está vacía. Tras las migraciones se carga cada archivo de data/seeds y después cada archivo de data/fixtures, a través del mismo servidor con el que hablan las pruebas — así los hooks de la aplicación se aplican a estos registros como a cualquier otra escritura. Un registro que el esquema actual rechaza detiene la ejecución y aparece nombrado en el error; vela fixtures regen reescribe los fixtures a partir del esquema.

Los archivos de prueba se ejecutan en paralelo contra una única base de datos, así que trata los seeds y los fixtures como una base de solo lectura: léelos y busca registros por id, pero crea tus propios registros para todo lo que una prueba modifique o elimine. Las pruebas generadas ya funcionan así.