Correr la suite de tests

Chinaski incluye su propio harness de tests: t/ más el bootstrap compartido t/helper.pl. Aproximadamente 120 archivos de test, todos ejecutables con un solo comando.

En una línea

CHINASKI_SECRET=ci-test-secret prove -lr t/

Esa es la misma invocación que usa el CI del proyecto (prove -lr t/ en cada push y cada PR a main), con el secret definido en el entorno de CI. Los archivos individuales corren a demanda: perl t/pages.t o prove -l t/pages.t.

Qué provee helper.pl

Los archivos de test se auto-inicializan sin boilerplate:

setup_test_env define el secret de sesión y MOJO_MODE=test, construye una base de datos SQLite temporal fresca desde el schema.sql real, apunta CHINASKI_DB hacia ella, y define un directorio de documentos por corrida para que los archivos de prueba nunca colisionen entre usuarios ni entre corridas. También pre-crea el directorio de salida de build (ignorado por git) para que el chequeo de salida escribible del /health no falle como falso positivo en un checkout fresco.
El cleanup está registrado, un bloque END elimina los sidecars WAL de la DB temporal y el directorio de docs por corrida. Ambos solían acumularse entre corridas en la propia máquina del proyecto antes de esa corrección, así que el cleanup es de carga crítica.
Seed data, dos cuentas (admin/admin123 con el rol admin, editor/editor123 con el rol editor) contra un site de dos idiomas (en, es), hasheadas con bcrypt en el momento del setup.
Login helpers ejecutan todo el flujo de inicio de sesión, obtienen la página de login, hacen scrape del token CSRF, envían las credenciales, aterrizan en /admin.
La aplicación bajo test es la cms.pl de producción misma cargada en un harness Test::Mojo (con el flag Secure de la cookie de sesión deshabilitado para el loop de test sin HTTPS); la suite siempre prueba el código incluido, nunca un stub.

Obtener acceso en los tests

login_admin y login_editor manejan los detalles incluyendo el scrape del token CSRF desde la página de login renderizada. Los tests que necesitan control más fino pueden golpear las rutas directamente con los token helpers.

Prerrequisitos de entorno

El mismo conjunto de dependencias que la app (Perl 5.26+, Mojolicious, DBI/DBD::SQLite, Template, Imager, DateTime, módulos Crypt, sqlite3 para configurar la DB).
El workflow de CI hace además de documentación de la receta de aprovisionamiento del lado del host (librerías de sistema más una lista de instalación con cpanm), y corre en un runner self-hosted colocado junto al host de despliegue, las dependencias se aprovisionan una vez a nivel de sistema, no por corrida.

El servidor MCP probado por separado

chinaski-mcp/mcp.t es la suite propia del servidor MCP. Define el CHINASKI_API_URL/CHINASKI_API_KEY requeridos por test (el servidor se niega a arrancar sin ambos) y prueba el comportamiento del protocolo orientado a la API en aislamiento.

Convenciones que vale la pena conocer

Los archivos de test que invocan al builder definen CHINASKI_TEST=1, porque el builder de lo contrario se niega a correr como root.
Los archivos con prefijo numérico (00-compile.t, 01-schema.t, 02-media-sniff.t, 03-util.t, 04-webhook.t) actúan como chequeos pre-vuelo, un build roto o un cambio de schema se manifiesta ahí primero en una pasada de prove -lr t/ antes de que lo haría cualquier test de feature.
La suite se desarrolla para Linux (el runner de CI es Linux; el CI corre el mismo toolchain que los despliegues de producción).