Auditoria de Testes
Este skill tem dois modos:
- Autoria. A barreira de autoria abaixo se aplica a todo teste que você adicionar ou alterar.
- Auditoria. Remova provas de baixo valor em lotes coerentes agrupados por dono da produção. Nunca persiga contagens de exclusão; o objetivo é uma suíte onde cada contrato tenha um dono forte, não um número menor.
Para uma campanha que pode toda a superfície de teste de um subsistema de uma só vez, leia CAMPAIGN.md primeiro.
Barreira de autoria
Antes de adicionar um teste, responda estas quatro perguntas:
- Que comportamento observável, invariante ou contrato independente ele protege?
- Que regressão crível o faria falhar?
- Por que a prova existente não cobre isso? Cada contrato deve ter um dono principal na fronteira mais forte. Um teste em outra camada precisa de um risco de transporte ou ciclo de vida distinto para ser justificado. Estenda tabelas existentes e fixtures compartilhadas em vez de adicionar quase-cópias, e consolide a configuração repetida.
- Ele precisa de um export, flag, wrapper ou gancho de injeção que não tenha chamador em produção? Se sim, mova a prova para a fronteira real.
Regras de suporte:
- Use o guia de fronteira e custo para escolher onde o teste vive e quanto ele pode custar.
- Um teste de regressão deve falhar antes da correção pelo motivo pretendido e passar após o reparo. Se você não puder mostrar a falha pré-correção, informe isso no seu relatório.
- Uma regressão na fronteira dona cobre o bug. Nunca a repita em cada camada que o bug cruzou.
- Uma refatoração que preserva comportamento não deve quebrar o teste.
Padrões de lixo
- Rejeite autocomparações, inventários copiados, buscas no código-fonte, asserções de implementação ou formato de chamada, contratos duplicados, seams exclusivos de teste, valores esperados gerados pelo sujeito do teste e mocks que fornecem o comportamento que está sendo assertado.
- Fixtures não devem fabricar recibos ou ordenação que o dono deveria produzir, e não devem alegar persistência por um caminho que o código nunca escreve.
- Um controle negativo deve falhar na guarda pretendida, e o nome de um teste deve corresponder ao comportamento que ele realmente exercita.
- Ao auditar candidatos, use a lista de verificação completa.
Barreira de retenção
- Mantenha testes que protegem contratos independentes: API pública, SDK, protocolo, configuração, migração, armazenamento, segurança, plataforma, padrões, bytes de prompt, saída gerada entre linguagens, empacotamento, release, arquitetura e ordenação observável. Ser estático ou lento não torna um teste descartável.
- Inspeção de código-fonte é aceitável apenas quando sobrevive a refatorações apenas de identificadores e protege um contrato independente voltado ao usuário.
- Um teste de base falhando pode ser um bug de produto a ser reparado, não um teste a ser deletado.
Auditoria e validação
- Antes de qualquer edição de auditoria, leia a evidência candidata e fluxo de trabalho. Inspecione os donos, chamadores e histórico completos, e registre que prova permanece antes de deletar qualquer coisa.
- Delete seams de produção obsoletos juntamente com seus testes. Nunca otimize por contagens de exclusão.
- Não edite o checkout enquanto uma execução de teste estiver em andamento. Execute o comando de teste focado do projeto para o dono e testes irmãos, execute as verificações de arquivos alterados do projeto e, em seguida, obtenha uma revisão antes de finalizar.
- Relate as causas, os contratos retidos, a prova e seu custo, linhas de código de produção versus teste alteradas e próximos passos. Commit, push ou finalize apenas quando a tarefa lhe der essa autoridade.