SkillEngenhariaQA
Reviewing Test Coverage
Avalia se os testes do PR cobrem adequadamente comportamentos novos, edge cases e cenários de falha.
Ações
PerfilDev
ProfundidadeMédia
Idiomaen-US
Objetivo
Em uma frase.
Avaliar se os testes do PR cobrem adequadamente o comportamento novo ou modificado — verificando cobertura de fluxos principais, edge cases e cenários de falha, e avaliando se os testes existentes são robustos ou frágeis.
Aplicação
Quando
faz sentido.
Usar
- Como etapa de revisão de testes de qualquer PR que adiciona ou modifica lógica de negócio.
- Quando há suspeita de que testes foram escritos apenas para aumentar percentual de cobertura, sem cobrir comportamento real.
- Quando o PR altera código em módulos historicamente propensos a regressão.
Não usar
- Para PRs de chore (formatação, configuração) sem lógica nova.
- Para escrever os testes faltantes — use writing-tests.
- Antes de executar reviewing-logic-and-correctness — os caminhos de lógica mapeados lá são a referência para avaliação de cobertura.
Prompt
Instruções
para a IA.
Passo 1 — Mapear comportamentos novos ou modificados
Com base nos caminhos de lógica identificados em `reviewing-logic-and-correctness`, listar todos os comportamentos que precisam de cobertura de teste:
- Cada novo caminho de execução adicionado (fluxos condicionais, funções novas).
- Cada comportamento existente que foi modificado.
- Cada edge case identificado durante a revisão de lógica.
- Cada cenário de erro: exceções lançadas, valores inválidos, falhas de dependência.Este mapa de comportamentos é a referência para avaliar se os testes são suficientes.
Passo 2 — Verificar cobertura dos fluxos principais
Para cada comportamento principal listado no Passo 1:
- Há um teste que executa este comportamento de ponta a ponta?
- O teste verifica o resultado correto (não apenas que nenhuma exceção foi lançada)?
- O teste usa inputs representativos — não apenas o caso mais simples?Sinalizar comportamentos sem nenhum teste correspondente.
Passo 3 — Verificar cobertura de edge cases e cenários de falha
Para cada edge case e cenário de falha listado no Passo 1:
- Input nulo ou vazio está testado?
- Valores limite estão testados (zero, negativo, máximo, mínimo)?
- Falhas de dependências externas estão testadas (DB offline, API retornando 500, timeout)?
- Exceções esperadas estão sendo verificadas por tipo e mensagem?
- Comportamento de rollback ou cleanup em caso de falha está testado?Edge cases sem cobertura são os cenários mais propensos a produzir bugs silenciosos em produção.
Passo 4 — Avaliar qualidade dos testes existentes
Para cada teste presente no PR, avaliar se é robusto ou frágil:
**Testes frágeis (sinalizar):**
- Testes que verificam detalhes de implementação em vez de comportamento externo observável.
- Testes que dependem de ordem de execução entre testes no mesmo suite.
- Testes que usam mocks excessivos a ponto de não testar a integração real entre componentes.
- Testes com assertions vagas como `expect(result).toBeTruthy()` sem especificar o valor correto.
- Testes que dependem de timing (sleeps, timeouts fixos) em vez de controle determinístico.
- Testes sem nenhuma assertion (apenas verificando que não lançou exceção quando havia resultado a verificar).**Testes robustos (confirmar):** - Verificam comportamento externo, não implementação interna. - São independentes entre si (podem rodar em qualquer ordem). - Usam dados de teste representativos do mundo real. - Têm assertions específicas e verificáveis.
Passo 5 — Verificar nomenclatura e rastreabilidade
Para cada teste no PR:
- O nome do teste descreve o comportamento que está sendo testado? (ex: `should return 404 when user does not exist` é bom; `test1` é ruim)
- É possível, lendo apenas o nome do teste, entender o que falhou quando o teste quebra?
- Testes de regressão para bugs específicos referenciam o ticket ou bug que motivou o teste?---
Casos
Exemplos
de uso.
---
## Exemplo 1 — Cobertura incompleta de edge cases em função de descontoConstelação
Onde
ela vive.
Bundles que incluem