TestSprite — cobertura e2e¶
O que é¶
Checagem e2e black-box: gera e roda os próprios testes contra o app no ar, exercitando
o produto por fora (fluxos, endpoints). É o par do agente test-writer (white-box, unit/
integração a partir do PRD) — um cobre por dentro, o outro por fora. Regra que orienta o
desenho: o dev GERA os testes, uma GitHub Action RODA, e o pr-guardian só LÊ o
resultado. Produção nunca é tocada em nenhuma camada.
As duas camadas¶
| Camada 1 — local | Camada 2 — PR/staging | |
|---|---|---|
| Dispara | o dev, no to-build |
Action testsprite.yml, no PR |
| Contra o quê | stack local (pnpm up + seed) |
staging (--target-url) |
| Pra quê | gerar os testes + confirmar de ponta a ponta | re-rodar a suíte committada (regressão) |
| Custo/setup | MCP + key na máquina do dev | zero por dev, secrets do repo |
O que vira teste (e o que não)¶
Estado atual (2026-07-08): OPT-IN pelo arquivo. Existe teste committado
(.testsprite/) → a Action roda; não existe → não roda. A decisão "é crítico?" é a régua
única criticidade: crítico → vira teste (happy path + 1–2 falhas de maior valor);
não-crítico → fica com o test-writer ou nada.
Dois formatos: UI (frontend, dirige o navegador) e API (backend, bate no endpoint). Não vira TestSprite: lógica pura/cálculo, edge case, refactor sem mudança de comportamento, helper interno, cosmético, miolo de job/cron (mas o endpoint que dispara, sim). Regra de ouro: 1 fluxo crítico = 1 teste de fluxo, não 1 teste por função.
Consequência pro Guardian (hoje): sem_teste numa área sem teste committado é o
esperado, não sinaliza. Só sinaliza se existe teste committado mas o check não veio.
Camada 1 — local (no to-build)¶
No passo Verify: testsprite_bootstrap (1ª vez) → generate test plan →
generate_code_and_execute contra o stack local (pnpm up). Loop de auto-validação: roda
→ se falha, conserta → re-roda até verde → só então commita .testsprite/ +
testsprite_tests/ junto com o código. Nunca aponta pra produção.
Camada 2 — PR/staging (Action testsprite.yml)¶
Quando existe teste committado: publica o código do PR em staging (git push -f), migra
o Supabase de staging, espera o deploy subir (poll no 200), roda a suíte
(testsprite test run --all --target-url <staging>). exit != 0 → check vermelho.
Dormente até existir teste committado — a Action sai verde sem fazer nada. Um PR por vez
(staging único). Ambiente fixo e versionado no YAML — garantia de nunca-prod.
pr-guardian só lê o check¶
Não executa nada — lê com gh pr checks. Verde → testsprite: verde. Vermelho → risco
funcional, 🚫, comenta os casos que falharam. Sem check (sem teste committado) →
testsprite: sem_teste, sinaliza sem inventar. Job incompleto → testsprite: nao_verificado,
não trava. Detalhe do papel do pr-guardian: comite-de-agentes.
Por que GitHub Action, não o GitHub App do TestSprite¶
Decisão 2026-07-07: consistência com os outros gates (ci-api/ci-crm, também Actions),
controle do ambiente versionado no YAML (nunca prod escondido em dashboard), e sem app de
terceiro com permissão de escrita na org.
Regressão e multi-dev¶
Suíte committada = re-rodada no PR de qualquer dev — pega "impactou uma feature que já existia" sem configuração por pessoa. Camada PR/staging = zero setup por dev; camada local = só quem cria teste novo precisa do MCP.
Ambiente — nunca produção¶
Staging: Supabase gfvvsodkehlhgnajpyxd, Railway env dedicado. Produção
(tfpsqcrhtnvlofypzhrl) intocável — não aparece no workflow.
Relacionado¶
engenharia-regenerativa · comite-de-agentes · skills · visao-geral