# 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](/es/seeds) y después los [fixtures](/es/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`](/es/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 `.server.test.ts` junto a cada [workflow](/es/workflows); una prueba de workflow arranca un worker en el proceso de pruebas, así que la ejecución se completa ahí. [`vela generate form`](/es/generate/form) y [`vela enable ai`](/es/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`](/es/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í.