Referencia del Test Helper

t/helper.pl es la librería compartida de la suite de tests: el constructor de fixtures y las utilidades de login que todo archivo de test usa. Esta página es la referencia ojo-de-programador de las piezas que provee. (Para cómo correr la suite, ver la página running-tests; para qué se prueba, ver la página de cobertura.)

setup_test_env

El constructor de entorno, invocable desde cualquier archivo de test:

Define el secret de sesión a un valor de test conocido y MOJO_MODE=test (la rama de modo test del CMS ejecuta el trabajo diferido de forma síncrona, así los tests no esperan timers).
Crea una base de datos SQLite temporal fresca (File::Temp, UNLINK-solo-el-archivo-principal) construida statement por statement desde el schema.sql real, con las secciones INSERT de seed de users y settings removidas para que las seeds de la propia suite sean autoritativas.
Habilita la aplicación de foreign keys (PRAGMA foreign_keys = ON).
Apunta CHINASKI_DB al archivo temporal, CHINASKI_DOCS_DIR a un path anidado por corrida (<db>.docs/documents), y crea el directorio output/ de la app si falta (está en el gitignore; los checkouts frescos en CI fallarían de otro modo el chequeo de output-dir escribible del /health en tests que lo ejercitan).
Registra el cleanup en un bloque END: los sidecars -wal/-shm de WAL y el árbol de docs, que los trucos de unlink de SQLite nunca atrapan.
Siembra dos users con contraseñas hasheadas con bcrypt generadas en runtime vía Crypt::Passphrase (admin/admin123, editor/editor123) y un site de dos idiomas (en, es).
Finalmente carga la aplicación real (require cms.pl) y expone el harness como $t = Test::Mojo->new (globals de paquete compartidos, así cada test puede $t->get_ok(...) justo después de la llamada).

login_admin / login_editor

Manejan un inicio de sesión completo:

GET /login (200).
Extraer el token CSRF del formulario renderizado (csrf_token" ... value="…") vía una regex: coincidiendo con cómo se valida el CSRF de login del lado servidor.
POST de las credenciales con el token, esperar la redirección 302, luego asertar que el header Location coincida con el área de admin (la app puede redirigir a un path return_to guardado cuando el login fue precedido por una URL protegida, por eso el test aserta solo el prefijo).

Otros bits exportados

$t y $dbh son globals de paquete para que los tests puedan manejar llamadas HTTP o entrar directamente a la DB cuando lo necesiten.
Las funciones helper son nombres exportados vía la lista de módulos (setup_test_env, login_admin, login_editor, $t, $dbh).

Convenciones

Los archivos que necesitan el harness llaman setup_test_env() justo después de hacer use/require de helper.pl; cualquier cosa antes de esa llamada no tiene app ni DB.
Las mutaciones de estado local deben quedar dentro de la propia sesión del archivo de test; el harness no resetea nada entre tests dentro de un mismo archivo (eso es aislamiento por archivo, no por aserción).
Los tests que hacen shell-out al builder definen CHINASKI_TEST=1 ellos mismos; el helper no lo hace.