Verificação com Prova de Comportamento

O que Verificação com Prova de Comportamento faz?

Use ao revisar implementação existente, trabalho delegado ou prontidão para entrega. Um comando verde, revisão estática ou resumo de agente não é prova a menos que exerça o comportamento reivindicado.

Quando Usar

• Um agente diz que uma tarefa está concluída.
• Testes passam, mas sua força comportamental é desconhecida.
• Uma correção de bug, mudança de UI, integração ou mudança operacional precisa de validação.
• Uma revisão estática conflita com comportamento previamente verificado em tempo de execução.

Não use isso em vez de test-driven-development para código novo; use para validar as evidências depois ou junto com a implementação.

Procedimento

1. Nomeie o comportamento reivindicado.

   • Declare o resultado visível ao usuário ou observável externamente que está sendo afirmado.
   • Conclusão: a reivindicação pode ser testada sem referência a detalhes de implementação.

2. Escolha o ponto de teste real mais próximo.

   • Prefira interação com componente montado, solicitação de integração, invocação de CLI, chamada de API ou fluxo ponta a ponta em vez de um teste apenas de importação ou snapshot.
   • Use cargas úteis realistas e fixtures com formato de produção.
   • Conclusão: a prova atinge o caminho de código cujo comportamento está sendo reivindicado.

3. Prove que a prova tem "dentes".

   • Para comportamento alterado ou removido, primeiro observe uma falha sem a implementação ou com um no-op deliberado quando seguro.
   • Um teste que permanece verde quando a unidade alterada é ignorada é vazio e não deve ser usado como evidência.
   • Conclusão: a prova pode distinguir o comportamento funcional do comportamento quebrado relevante.

4. Execute e inspecione a prova.

   • Execute a verificação focada e, em seguida, as verificações mais amplas aplicáveis do projeto.
   • Leia o teste ou harness em vez de confiar em um resumo de seu autor.
   • Conclusão: a saída e a implementação ambas suportam a reivindicação exata.

5. Lide com evidências conflitantes.

   • Trate o comportamento em tempo de execução verificado pelo usuário como evidência que requer explicação antes de substituí-lo por uma recomendação de revisão estática.
   • Rastreie o framework, cache, infraestrutura ou semântica de tempo de execução que causam a aparente contradição.
   • Conclusão: qualquer mudança segue a evidência mais forte disponível, não a confiança do revisor.

Armadilhas

• Não verifique comportamento do console do navegador com Node. O console.log do Node não suporta %c — ele trata strings de estilo como argumentos simples e as descarta silenciosamente, então um harness Node/Python imprime uma grade limpa e mascara uma renderização DevTools quebrada. Para verificar saída do console, dirija o navegador real via CDP (headless Chrome --remote-debugging-port + um script WebSocket capturando Runtime.consoleAPICalled), ou obtenha evidência visível ao usuário do console real. Um harness que roda em um engine de console diferente não é prova.
• Um console.log com muitos segmentos %c transborda o DevTools. O formatador de console consome argumentos um especificador por vez; quando uma única chamada tem muitos segmentos estilizados (ex. ~193), as strings de estilo finais não são consumidas como estilos — elas imprimem literalmente como texto não formatado (o clássico despejo de lixo color:#...;font-family...). Remédio conforme documentação do Chrome: um console.log por linha/linha, cada um com um número limitado de execuções %c. É por isso que arte ASCII por caractere como um gigante console.log('%c%s%c%s...') vaza estilos.
• "Renderiza sem lançar exceções", fixtures apenas de tipo, mocks que substituem a unidade sob teste e testes .todo() não provam comportamento.
• Nunca mude o comportamento de produção meramente para satisfazer scaffolding de teste superficial.
• Não declare conclusão quando uma dependência externa, interação de UI ou caminho de implantação não foi exercido; relate o limite não verificado.

Verificação

Um relatório de conclusão deve incluir: o comportamento provado, o comando ou ação exata usada, o resultado observado e qualquer limite que permanece não verificado.