ai-dev-skillset: Skill for Claude Code

Qualidade e Cobertura de Testes

Use esta skill junto da skill de TDD em qualquer mudança de software.

Regras

• Garanta ao menos 80% de cobertura automatizada para o módulo alterado ou para o projeto quando a ferramenta medir apenas cobertura global.
• Configure o comando de cobertura para falhar abaixo de 80% quando a stack oferecer suporte prático a limiar mínimo.
• Se a ferramenta de cobertura não existir, adicione-a como dependência de desenvolvimento do projeto pelo gerenciador da stack antes de considerar a medição indisponível.
• Para Python, use sempre uv: adicione coverage, pytest-cov ou ferramenta equivalente com uv add --dev, execute com uv run e registre a configuração em pyproject.toml quando aplicável.
• Configure a cobertura para medir o pacote ou módulo de produção inteiro, não apenas os arquivos importados acidentalmente pelos testes.
• Não aumente cobertura com testes vazios, snapshots sem asserção relevante ou testes que só exercitam código sem validar comportamento.
• Priorize cobertura de regras de domínio, casos de uso, validações, cálculos, parsing, serialização e fluxos de erro.
• Teste e2e e obrigatorio quando o modulo (a) persiste estado externo — arquivo, banco, fila, cache, message broker, request HTTP de saida — OU (b) expoe entrypoint executavel — CLI, HTTP server, daemon, worker, cron job. Nesses casos, alem de unit e integration, inclua pelo menos um teste e2e do fluxo completo a partir do entrypoint real. Integration sozinho NAO substitui e2e: integration valida o adapter contra o recurso; e2e valida o fluxo cross-command/cross-request inteiro, incluindo parsing, wiring e estado final observavel.
• E2E em CLI: invoque a CLI compilada (ou main()/runCli() chamada como subprocesso ou in-process) com argv, capture exit code, stdout e stderr, e VERIFIQUE o estado do recurso externo (arquivo, banco) depois de uma sequencia de comandos representativa. Exemplo: add "X" -> list -> done <id> -> list --done, verificando que o arquivo persistido contem a tarefa com status: "done".
• E2E em HTTP server: suba o servidor (ou use supertest), chame os endpoints na ordem do fluxo real (criar -> ler -> atualizar -> ler), verifique status e payload de resposta E o estado final do recurso externo.
• E2E nao substitui unit/integration. Os tres niveis convivem: unit cobre regras puras com a maior densidade; integration cobre adapters contra recursos reais; e2e cobre o fluxo completo do ponto de entrada ate o estado final.
• E2E nao e so caminho feliz. Um unico e2e do happy path satisfaz o minimo absoluto, mas modulo com autorizacao, validacao cruzada ou multiplos comandos precisa de e2e tambem para os fluxos de erro criticos. No minimo: (1) sequencia feliz cross-command; (2) acesso negado por permissao (permission_denied); (3) recurso inexistente (not_found); (4) validacao de entrada falhando no entrypoint. Cada e2e verifica exit code, stderr, e estado do recurso externo (nao mutado em caminhos de falha).