Skip to main content
failproofai possui dois conjuntos de testes: testes unitários (rápidos, com mocks) e testes end-to-end (invocações reais de subprocessos).

Executando os testes


Testes unitários

Os testes unitários ficam em __tests__/ e usam o Vitest com jsdom.

Escrevendo um teste unitário de política


Testes end-to-end

Os testes E2E invocam o binário real do failproofai como subprocesso, enviam um payload JSON via stdin e verificam a saída no stdout e o código de saída. Isso testa o caminho de integração completo que Claude Code utiliza.

Configuração

Os testes E2E executam o binário diretamente a partir do código-fonte do repositório. Antes da primeira execução, compile o bundle CJS que os arquivos de hooks customizados utilizam ao importar de 'failproofai':
Em seguida, execute os testes:
Recompile o dist/ sempre que alterar a API pública de hooks (src/hooks/custom-hooks-registry.ts, src/hooks/policy-helpers.ts ou src/hooks/policy-types.ts).

Estrutura dos testes E2E

Usando os helpers E2E

FixtureEnv - ambiente isolado por teste:
createFixtureEnv() registra a limpeza via afterEach automaticamente. runHook - invoca o binário:
Payloads - fábricas de payload prontas para uso:

Escrevendo um teste E2E

Formatos de resposta E2E

Configuração do Vitest

Os testes E2E usam vitest.config.e2e.mts com:
  • environment: "node" - sem necessidade de globals do navegador
  • pool: "forks" - isolamento real de processos (os testes iniciam subprocessos)
  • testTimeout: 20_000 - 20s por teste (inicialização do binário + avaliação do hook)
O pool forks é importante: workers baseados em threads compartilham o globalThis, o que pode interferir em testes que iniciam subprocessos. Forks baseados em processos evitam esse problema.

CI

A execução completa de CI (bun run lint && bunx tsc --noEmit && bun run test:run && bun run build) deve passar antes do merge. O conjunto de testes E2E é executado como um job de CI separado, em paralelo. Consulte Contributing para o checklist completo pré-merge.