Rodando a Suíte de Testes

O Chinaski distribui seu próprio harness de testes: t/ mais o bootstrap compartilhado t/helper.pl. Cerca de 120 arquivos de teste, todos executáveis com um comando.

Em uma linha

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

Essa é a mesma invocação que o CI do projeto usa (prove -lr t/ a cada push e a cada PR para main), com o secret definido no ambiente do CI. Arquivos individuais rodam sob demanda: perl t/pages.t ou prove -l t/pages.t.

O que o helper.pl fornece

Os arquivos de teste fazem o bootstrap sem boilerplate:

setup_test_env define o secret de sessão e MOJO_MODE=test, constrói um banco SQLite temporário novo a partir do schema.sql real, aponta CHINASKI_DB para ele e define um diretório de documentos por execução, para que arquivos temporários nunca colidam entre usuários ou execuções. Ele também pré-cria o diretório de saída do build (ignorado pelo git) para que a verificação de saída gravável do /health não falhe como falso positivo em um checkout novo.
A limpeza é registrada: um bloco END remove os sidecars WAL do banco temporário e o diretório de documentos por execução. Ambos se acumulavam entre execuções na própria máquina do projeto antes dessa correção, então a limpeza é essencial.
Dados de seed: duas contas (admin/admin123 com o papel admin, editor/editor123 com o papel editor) em um site de dois idiomas (en, es), com hash bcrypt na hora do setup.
Helpers de login executam todo o fluxo de entrada: buscam a página de login, extraem o token CSRF, enviam as credenciais e chegam em /admin.
O app sob teste é o próprio cms.pl de produção carregado em um harness Test::Mojo (com a flag Secure do cookie de sessão desativada para o loop de teste sem HTTPS); a suíte sempre testa o código distribuído, nunca um stub.

Obtendo acesso nos testes

login_admin e login_editor cuidam dos detalhes, incluindo a extração do token CSRF da página de login renderizada. Testes que precisam de controle mais fino podem acessar as rotas diretamente com os helpers de token.

Pré-requisitos de ambiente

O mesmo conjunto de dependências do app (Perl 5.26+, Mojolicious, DBI/DBD::SQLite, Template, Imager, DateTime, módulos Crypt, sqlite3 para o setup do banco).
O workflow de CI serve também como documentação da receita de provisionamento no host (bibliotecas de sistema mais uma lista de instalação do cpanm), e roda em um runner self-hosted colocalizado com o host de deployment; as dependências são provisionadas uma vez em todo o sistema, não a cada execução.

O servidor MCP, testado separadamente

chinaski-mcp/mcp.t é a suíte própria do servidor MCP. Ela define o obrigatório CHINASKI_API_URL/CHINASKI_API_KEY por teste (o servidor se recusa a iniciar sem ambos) e testa o comportamento do protocolo voltado à API isoladamente.

Convenções que vale conhecer

Arquivos de teste que chamam o builder por shell definem CHINASKI_TEST=1, porque o builder, caso contrário, se recusa a rodar como root.
Arquivos com prefixo numérico (00-compile.t, 01-schema.t, 02-media-sniff.t, 03-util.t, 04-webhook.t) atuam como verificações preliminares; um build quebrado ou uma mudança de schema aparece ali primeiro em uma passada de prove -lr t/, antes de qualquer teste de funcionalidade.
A suíte é desenvolvida para Linux (o runner de CI é Linux; o CI roda a mesma toolchain dos deployments de produção).