Referência da Test Helper

t/helper.pl é a biblioteca compartilhada da suíte de testes: o construtor de fixtures e os utilitários de login que todo arquivo de teste usa. Esta página é a referência do ponto de vista do programador para as peças que ele fornece. (Para rodar a suíte, veja a página running-tests; para o que é testado, veja a página de cobertura.)

setup_test_env

O construtor de ambiente, chamável de qualquer arquivo de teste:

Define o session secret para um valor de teste conhecido e MOJO_MODE=test (o ramo de modo de teste do CMS dispara o trabalho adiado de forma síncrona, para que os testes não esperem por timers).
Cria um banco de dados SQLite temporário novo (File::Temp, com UNLINK apenas do arquivo principal), construído instrução por instrução a partir do schema.sql real, com as seções de INSERT de seed para usuários e configurações removidas, de modo que os seeds da própria suíte sejam os autoritativos.
Habilita a imposição de chaves estrangeiras (PRAGMA foreign_keys = ON).
Aponta CHINASKI_DB para o arquivo temporário e CHINASKI_DOCS_DIR para um caminho aninhado por execução (<db>.docs/documents), e cria o diretório output/ do app se estiver ausente (ele está no gitignore; checkouts novos no CI falhariam, caso contrário, na checagem de output-dir gravável do /health nos testes que a exercitam).
Registra a limpeza em um bloco END: os sidecars -wal/-shm do WAL e a árvore de docs, que os truques de unlink do SQLite nunca pegam.
Semeia dois usuários com senhas com hash bcrypt geradas em tempo de execução via Crypt::Passphrase (admin/admin123, editor/editor123) e um site com dois idiomas (en, es).
Por fim, carrega a aplicação real (require cms.pl) e expõe o harness como $t = Test::Mojo->new (globais de pacote compartilhadas, de modo que todo teste pode chamar $t->get_ok(...) logo após a chamada).

login_admin / login_editor

Executam um login completo:

GET /login (200).
Extraem o token CSRF do formulário renderizado (csrf_token" ... value="…") por meio de uma regex, espelhando a forma como o CSRF de login é validado no servidor.
Fazem POST das credenciais com o token, esperam o redirect 302 e então verificam que o header Location corresponde à área de admin (o app pode redirecionar para um caminho return_to salvo quando o login foi precedido por uma URL protegida, e é por isso que o teste verifica apenas o prefixo).

Outros itens exportados

$t e $dbh são globais de pacote, para que os testes possam fazer chamadas HTTP ou acessar o banco diretamente quando necessário.
As funções auxiliares são nomes exportados pela lista do módulo (setup_test_env, login_admin, login_editor, $t, $dbh).

Convenções

Arquivos que precisam do harness chamam setup_test_env() logo após fazer use/require do helper.pl; qualquer coisa antes dessa chamada não tem app nem banco.
Mutações de estado local devem ficar dentro da própria sessão do arquivo de teste; o harness não reseta nada entre testes dentro de um arquivo (isso é isolamento por arquivo, não por asserção).
Testes que executam o build via shell definem CHINASKI_TEST=1 eles mesmos; o helper não define.