# Rubrica: Cobertura de Testes (Peso 20%)

Avalia se os testes cobrem os comportamentos esperados, são isolados e têm nomes úteis.

## Score 9-10 — Exemplar

- **Cada pós-condição do use case referenciado tem teste correspondente.** Se a task traz `usecase: "UC-07"`, abra `2-plan/usecases/UC-07-*.md` e percorra as pós-condições (P1, P2…): cada uma precisa de ao menos um teste que a verifique. Pós-condição sem teste **impede a faixa 9-10**, por mais completa que a suíte pareça no resto.
- Happy path coberto para todos os casos de uso relevantes — "relevantes" são os use cases referenciados pelas tasks da feature, não uma lista implícita.
- Fluxos alternativos do use case (A1, A2…) cobertos: são os edge cases de **comportamento** e foram declarados justamente para serem testados.
- Edge cases críticos cobertos: null/undefined, string vazia, boundary values, coleção vazia.
- Casos de erro cobertos: o que acontece quando a operação falha, quando a dependência retorna erro.
- Testes completamente isolados — cada teste pode rodar sozinho em qualquer ordem.
- Nomes de teste descrevem o comportamento esperado: `"deve retornar erro quando email já existe"` (não `"testEmail"`).
- Testes testam comportamento, não implementação — refatorar sem mudar comportamento não quebra testes.

## Score 7-8 — Bom

- Happy path coberto em todos os casos relevantes.
- Maioria dos edge cases cobertos, com poucos gaps identificáveis.
- Casos de erro cobertos para os fluxos principais.
- Isolamento correto na maioria dos testes.
- Nomes descritivos com raras exceções genéricas.

## Score 5-6 — Aceitável com ressalvas

- Happy path coberto, mas edge cases com cobertura parcial.
- Casos de erro não cobertos sistematicamente — só os mais óbvios.
- Alguns testes com dependências entre si (ordem importa).
- Nomes misturados: alguns descritivos, outros genéricos.
- Testes que testam implementação (dependentes de detalhes internos).

## Score 3-4 — Problemático

- Apenas happy path coberto, sem edge cases.
- Testes interdependentes ou com estado compartilhado.
- Nomes que não descrevem o comportamento testado.
- Cobertura presente mas superficial — testes passam mas não protegem contra regressão.

## Score 1-2 — Reprovado

- Ausência de testes ou testes que não verificam nada significativo.
- Testes que sempre passam independente do comportamento (sem asserts reais).
- Sem cobertura de qualquer edge case ou caminho de erro.
- Nomes completamente genéricos ou numerados.

## Perguntas de avaliação

0. A task referencia um `usecase`? Se sim: **toda** pós-condição daquele use case tem teste correspondente? (Sem isso, o teto é 8.)
1. O happy path está coberto para todos os casos de uso da tarefa?
2. Os edge cases críticos (null, vazio, boundary) estão cobertos?
3. O que acontece quando uma dependência falha — isso está testado?
4. Os testes podem rodar em qualquer ordem sem interferir entre si?
5. Os nomes dos testes descrevem o comportamento esperado sem precisar ler o corpo?
6. **Esta mudança é uma CORREÇÃO? Então: o que ela abriu?** Que comportamento antes correto pode ter
   regredido por causa dela, e existe teste que pegaria essa regressão? Toda pergunta acima olha para
   frente (o que a mudança deve fazer); esta olha para os lados. Numa feature real, três de três
   rodadas de correção abriram um problema novo — o fix de um shadow abriu um laço de LLM a cada 15
   min; o fecho de um fail-open abriu um P1; a correção desse P1 saiu com meio predicado. Nenhuma
   apareceu no score, porque score não pergunta isso. **Sem resposta a esta pergunta numa correção,
   o teto de Cobertura é 8.**
7. **Quantos testes desta task asseram sobre TEXTO DE ARQUIVO** (prompt, migration, config,
   markdown, código-fonte lido como string)? **Cada um tem substituto em runtime** — um teste
   que exercita o sistema ou, em critério sobre saída de LLM, a evidência em
   `3-implement/evidencias/{taskId}.md` apontando um eval? Teste de texto prova a VERSÃO do
   arquivo, não o comportamento: quando é o único teste de uma pós-condição, **a pós-condição
   conta como sem teste** (pergunta 0 — teto 8). Exceções: pós-condição com
   `> [!note] Por que artefato:` e o único teste de estrutura por fonte de prompt
   (`ai-agents-testing-ai`). Medido: 12 suítes, 106 testes sobre versões superadas do prompt.

## Tetos de prova (Gate 3)

No Gate 3 o avaliador independente pontua **a própria evidência** 0-10 nas cinco rubricas de
`.morph/framework/evals/proof-rubrics/` (`mutation-proof.md`, `verde-nao-e-coberto.md`,
`fiacao.md`, `guard-cego.md`, `eval-de-modelo.md`) e grava a linha `**Proof-Scores:**` no `evaluator-report.md`.

Elas **não** são dimensões do composto — nenhum peso muda por causa delas. Elas entram aqui, como
teto sobre esta dimensão, pelo mesmo mecanismo que "pós-condição sem teste impede a faixa 9-10":

| menor Proof-Score das cinco | teto nesta dimensão |
|---|---|
| 9 a 10 | sem teto |
| 7 a 8 | 8 |
| 4 a 6 | 6 |
| 0 a 3 | 3, e o item entra como **bloqueante** listado no relatório |

Sem a linha `**Proof-Scores:**`, não há teto a aplicar — mas a ausência da seção `## Mutações` num
relatório de feature com código de produção **pausa o Gate 3** por conta própria
(`src/lib/risk-detector.js`), antes de qualquer discussão de nota.