Testador do Campeonato WJTTC

"Nós quebramos coisas para que outros nunca precisem saber que elas foram quebradas."

Aplique padrões inspirados na F1 aos testes de software. Assim como os freios devem funcionar impecavelmente em ritmo de corrida, o código em produção também deve. Esta habilidade executa planos de teste e registra relatórios — é o piloto, não o engenheiro. Para planejar e gerar o conjunto de testes, use wjttc-builder.

Quando usar esta habilidade

• Executar um plano de teste existente ou recém-escrito e relatar os resultados
• Reproduzir e identificar a causa raiz de um bug reportado
• Validação de casos extremos / tratamento de erros / regressão
• Auditar se o sinal de CI do conjunto de testes ainda pode ser confiável
• Produzir um relatório WJTTC com um veredito de nível

Os cinco níveis do WJTTC

Triagem de cada teste pelo raio de impacto. Os três primeiros definem a gravidade; Pneu e Pit cobrem durabilidade e o portão de liberação.

Teste o Freio primeiro. Se os freios não funcionarem, nada mais importa.

Passo 0 — Pré-auditoria de Integridade do Sinal (execute ANTES de adicionar/executar qualquer coisa nova)

CI vermelho é um contrato: deve sempre significar "pare, olhe, corrija." Uma suíte com alta cobertura, mas com falhas intermitentes, é menos confiável do que uma suíte menor com zero alarmes falsos — porque a equipe parou de ler os alertas vermelhos. Corrija o sinal antes de adicionar mais testes.

Método — classifique os últimos 30 dias de falhas de CI:

Pontuação de Integridade do Sinal: SI = Real bugs / (Real bugs + Flakes + Infra) × 100

Eliminar à vista: asserções de desempenho de tempo absoluto rígidas em runners compartilhados (expect(t).toBeLessThan(30)) → mover para um fluxo de trabalho não restritivo; chamadas de rede na suíte principal → mockar na fronteira; testes de concorrência sem ordenação explícita; etapas dependentes de segredos que falham rigidamente quando ausentes → ignorar cinza.

A regra inversa: CI verde que passa enquanto algo está quebrado é igualmente uma violação. Se um bug real foi lançado apesar do CI verde, escreva o teste de regressão ANTES que a correção seja aplicada.

A conversa é o verdadeiro portão. O CI é infraestrutura de suporte para a auditoria humana + IA; CI intermitente desperdiça a largura de banda da auditoria. A Integridade do Sinal mantém o CI digno da conversa.

Loop de execução

1. Escopo — o que deve fazer? caminho feliz, casos extremos, modos de falha, metas de desempenho, nível de cada um.
2. Auditar sinal (Passo 0) antes de confiar ou estender a suíte.
3. Executar cada teste: configurar, preparar dados, executar, observar o real vs. o esperado, registrar aprovação/falha/bloqueado, capturar evidências em caso de falha.
4. Reproduzir deterministicamente cada falha; identificar a causa raiz; anotar a correção.
5. Verificação de cobertura por nível — confirmar que cada teste está nivelado:

   faf wjttc --path tests          # audit tier coverage (vendor-neutral)
   faf wjttc --strict --json       # CI gate: non-zero if any test is untiered
   

6. Relatório — registrar o relatório WJTTC (abaixo), então apresentar o veredito de nível.

Formato do relatório WJTTC

Salve os relatórios em ./wjttc-reports/ no projeto sob teste (ou em um caminho especificado pelo usuário). Nunca escreva em um caminho absoluto/pessoal. Nomeie os arquivos YYYY-MM-DD-{project}-{feature}-tests.yaml.

---
# Relatório de Teste WJTTC
projeto: "nome-do-projeto"

…