Verificação de teste com consciência de custo
Reduza trabalho e saída redundantes sem enfraquecer as verificações necessárias. Escolher uma ordem melhor pode economizar tempo de execução; relatórios concisos economizam contexto, mas não tornam um teste já em execução mais rápido. Não alegue economia sem medições.
Planejar e executar verificações
- Identifique componentes afetados, riscos, requisitos do projeto e verificações apropriadas antes de executar suítes caras. Siga requisitos explícitos do usuário e do projeto, incluindo verificações obrigatórias.
- Conclua primeiro a alteração principal e a cobertura de regressão direcionada significativa. Diagnostique e corrija falhas de construção ou comportamento com a verificação relevante mais restrita. Em seguida, estabilize cenários de integração ou ponta a ponta afetados. Para cenários compartilhados novos ou alterados, compare as expectativas com uma referência disponível; verifique e documente diferenças intencionais separadamente.
- Depois que a alteração e as verificações direcionadas estiverem estáveis, execute a suíte final necessária, verificações estáticas e construções conforme apropriado. Reutilize um resultado bem-sucedido apenas enquanto o código, dependências, configuração, ambiente e cenário relevantes permanecerem inalterados.
- Após uma correção, reexecute as verificações afetadas. Repita a suíte ampla quando o impacto for amplo, as dependências mudarem, os requisitos exigirem ou a correção permanecer incerta. Não repita automaticamente uma suíte completa para cada falha local.
- Para uma falha intermitente, preserve a primeira falha e reexecute o teste sozinho; se necessário, execute sua suíte em série para investigar interferência. Relate instabilidade não resolvida em vez de tratar uma execução posterior como prova de que a falha foi corrigida.
- Para alterações apenas de documentação, verifique o diff, links relevantes e sintaxe; execute testes de aplicação somente quando necessário ou relevante. Mantenha medições de desempenho isoladas de construções e testes concorrentes que possam distorcer resultados.
- Consulte trabalhos de longa duração em intervalos razoáveis, em vez de ler repetidamente a saída inalterada. Evite reiniciar o trabalho apenas para verificar o progresso.
Manter a saída útil e limitada
Prefira um executor de projeto existente ou recurso de relatório do framework. Capture stdout e stderr completos em um log único e sem sobrescrita quando apropriado, e retorne um resumo conciso: resultado do comando e status de saída, duração, contagens de teste reconhecíveis, incluindo testes ignorados ou pulados, e localização do log. Em caso de falha, inclua nomes de casos com falha e um trecho de diagnóstico limitado; inspecione a parte relevante do log completo se o resumo for insuficiente. Nunca infira sucesso geral a partir de contagens parciais da suíte: use o status de saída real do comando e indique quando um resumo não puder ser analisado. Preserve erros de inicialização, cancelamento e comportamento de sinal. Não empilhe wrappers redundantes em torno de um executor existente.
Verificar infraestrutura de teste
Ao criar ou alterar substancialmente um executor de teste, wrapper ou ferramenta de relatório, teste a confiabilidade de seus resultados. Escolha casos com base no que a ferramenta realmente faz e no risco de ocultar ou deturpar uma falha. Casos úteis incluem:
- Uma falha posterior após uma suíte bem-sucedida continua sendo uma falha, com o status de saída correto.
- A saída completa é retida mesmo quando os diagnósticos exibidos são limitados.
- Ignorados, erros de inicialização, resumos não reconhecidos e interrupções são relatados ou propagados corretamente, quando aplicável.
Exercite o comportamento observável, incluindo o limite com o processo de teste subjacente. Adapte a análise ao framework real e evite testes que apenas duplicam a implementação. Isso é verificação da infraestrutura, não um requisito para escrever testes para cada teste individual. Não reescreva ou teste novamente uma ferramenta existente confiável apenas porque esta skill é usada.
Escrever testes de diagnóstico
Mantenha testes bem-sucedidos silenciosos, a menos que a saída de progresso seja útil. Falhas devem identificar o caso, comportamento esperado e real, parâmetros relevantes e qualquer semente aleatória. Descreva cargas grandes com comprimentos, localização da incompatibilidade, trechos curtos ou hashes em vez de despejar tudo. Habilite detalhes por iteração ou rastreamentos completos para diagnóstico quando necessário. Marque ignorados explicitamente com motivos e nunca converta uma falha em uma saída bem-sucedida. Melhore testes existentes barulhentos ao trabalhar neles, em vez de reescrever uma suíte saudável apenas por formatação.