Auditoria de Testes OxideTerm
Mantenha proteção de regressão útil na camada que possui o comportamento. Use a menor revisão que resolva a alteração solicitada; julgue os resultados pelos contratos preservados e erros detectados, não por contagem de testes ou linhas deletadas.
Leia o AGENTS.md aplicável. Execute comandos a partir da raiz do repositório. A matriz de verificação e o guia de testes definem verificações específicas do projeto; esta skill fornece as decisões de qualidade do teste.
Escolha o Escopo
- Escrevendo ou alterando um teste: aplique as questões de autoria àquele comportamento e inspecione sua cobertura existente mais próxima.
- Diagnosticando uma falha: estabeleça por que o teste falhou e se a implementação, expectativa, fixture ou ambiente está errado antes de editar.
- Auditando testes existentes: revise o módulo ou comportamento solicitado e registre evidências para cada alteração proposta. Expanda para um subsistema inteiro somente quando esse escopo foi solicitado. Use o mesmo padrão de evidência para cada lote.
Criar ou invocar esta skill não autoriza uma limpeza ampla, subagentes, commits, pushes ou PRs. Respeite a autorização existente do usuário e qualquer limite de apenas revisão. Quando as edições já estiverem autorizadas e a evidência for suficiente, prossiga sem outra rodada de aprovação.
Questões de Autoria
Antes de adicionar ou alterar um teste, identifique:
- O comportamento observável ou contrato independente que está sendo protegido.
- Uma regressão plausível e a asserção particular que ela falharia.
- O que a cobertura existente mais próxima perde. Estenda essa cobertura quando apropriado; outra camada precisa de um risco distinto de integração, protocolo ou ciclo de vida.
- Se o teste exigiria uma exportação, switch, wrapper ou gancho de injeção de produção que não possui chamador de negócio. Prefira testar no limite proprietário existente.
Use valores esperados independentes da implementação. Fixtures devem distinguir o comportamento correto do bug provável: inclua candidatos excluídos ao testar filtros, chaves de ordenação diferentes ao testar ordenação e entrada sensível real ao verificar redação. Um round-trip de campo de construtor, um resultado não vazio ou um mock que executa o comportamento sendo afirmado é evidência insuficiente do workflow pretendido.
Auxiliares de teste e fixtures podem legitimamente ser apenas para teste. A preocupação é distorcer APIs de produção ou manter comportamento de produção obsoleto vivo apenas para testes.
Diagnosticando uma Falha de Teste
Leia o teste completo, suas entradas, o caminho de produção, a cobertura próxima e o histórico de alterações relevante. Para CI, identifique o commit com falha, job, nome do teste e asserção; uma saída genérica diferente de zero não é uma causa raiz. Inspecione o código-fonte ou tipos de dependência quando a afirmação depender de seu comportamento.
Classifique a falha a partir das evidências:
- Regressão de produto: o contrato pretendido ainda se mantém. Reproduza a falha e repare a implementação proprietária dentro do escopo autorizado.
- Expectativa obsoleta: o histórico e o contrato atual mostram uma mudança intencional de comportamento. Atualize o comportamento esperado enquanto retém proteção para formatos e APIs de versão suportados.
- Teste ou fixture com falha: o caso não exercita sua condição reivindicada, depende de estado acidental ou falha por um motivo não relacionado. Repare a configuração e as asserções no limite real.
- Falha de ambiente: compilação, dependências, recursos, plataforma ou fixtures externas impedem que o comportamento seja testado. Relate essa limitação; não a reinterprete como um teste aprovado ou obsoleto.
Uma falha de linha de base não é motivo para deletar um teste. Para uma correção de bug, demonstre a falha pretendida antes do reparo e o sucesso depois. Reutilize evidências de CI válidas ou uma linha de base local capturada quando provar a mesma falha; não repita verificações caras apenas por cerimônia.
Por exemplo, o teste do plugin .oxide precisa distinguir validação sem senha da visualização de importação descriptografada. A resposta de validação do formato criptografado não deve revelar metadados; a visualização com senha ainda deve conter os nomes de descrição e conexão explicitamente esperados. Atualizar essas asserções preserva o contrato sem outro teste de descriptografia de baixo nível na camada do plugin.
Audite Antes de Editar
Leia cada candidato completamente, incluindo linhas de parâmetros. Rastreie seu ponto de entrada de produção, chamadores, dependências relevantes, implementações irmãs e testes sobrepostos. Verifique o histórico para a razão de existir e o roteamento de CI para quais verificações realmente são executadas.
Use um registro de evidência compacto para alterações propostas, na resposta de trabalho a menos que um relatório salvo tenha sido solicitado:
| Teste e localização | Comportamento e falha crível | Decisão | Prova restante ou reparada | Validação |
|---|---|---|---|---|
| Nome exato do teste e caminho | O que as asserções podem detectar | Reter / Corrigir / Consolidar / Deletar | Teste ou limite nomeado, com histórico relevante | Comando focado ou cenário manual |
- Reter: protege independentemente um contrato significativo.
- Corrigir: o comportamento importa, mas a entrada, asserção, nome ou resultado esperado está errado ou muito fraco.
- Consolidar: mova asserções distintas para o teste primário nomeado antes de remover a configuração ou caso duplicado.
- Deletar: nomeie a prova restante mais forte, ou demonstre que o comportamento não possui mais um contrato suportado. Incerteza significa investigar ou reter.
Para código de produção removido com um teste, identifique também seus chamadores não teste e por que o código é obsoleto. Pesquise por referências antes de remover um auxiliar, exportação, feature ou fixture. Não faça simplificações não relacionadas parte da auditoria.
Padrões que Vale a Pena Investigar
- O teste repete o texto fonte da implementação, formato de chamada privada ou representação interna exata, e falha após um refator que preserva comportamento.
- Várias camadas chamam o mesmo auxiliar com entradas equivalentes e repetem suas asserções sem exercitar sua própria integração.
- Uma fixture pré-arranja a ordem de callback, notificação de conclusão ou resultado persistido que o proprietário real deveria produzir.
- Um teste de negação é rejeitado pela validação de parâmetros antes de alcançar a verificação de permissão que afirma testar.
- Um teste de concorrência, cancelamento ou ativação verifica apenas um sinalizador final sem criar o trabalho concorrente ou o waiter.
- Uma asserção de sucesso verifica apenas
Ok,Some, comprimento ou não-vazio quando conteúdo, identidade, ordenação ou um efeito colateral durável é o contrato.
Estes são sinais de investigação, não regras automáticas de exclusão. Preserve padrões de segurança independentes, bytes de protocolo, formatos de persistência e migração, APIs de plugin, comportamento de plataforma, empacotamento, internacionalização e restrições de arquitetura. Inspeção estática pode ser útil quando guarda um contrato real e sobrevive a renomeação irrelevante. Execução lenta sozinha não torna um teste redundante.
Limites do OxideTerm
| Comportamento | Limite de verificação preferido |
|---|---|
| Parsing, normalização de configurações, serialização ou mesclagem de dados | Crate de domínio proprietário com valores esperados explícitos e amostras de formato suportadas |
| Compartilhamento de nós SSH, SFTP, forwarding, reconexão ou hosts de salto | Proprietário de runtime com registro, cancelamento e limpeza de consumidor real; veja propriedade de runtime |
| Páginas mistas, foco, popups ou resultados de UI tardios | Contexto de teste GPUI existente e entity de feature; IME nativo, janela e comportamento de GPU ainda exigem validação de host |
| Plugin, MCP ou adaptador CLI | Despacho real e dados retornados, autoridade, identidade de alvo ou efeito colateral; evite reproduzir o auxiliar de domínio sozinho |
| Redação e tempo de vida de credenciais | Entrada secreta sintética através do limite de saída ou propriedade relevante; veja dados sensíveis |
| Empacotamento e scripts de repositório | Testes de script existentes ou o contrato de dry-run real selecionado pela matriz de verificação |
Para um teste de nó compartilhado, fechar um terminal deve deixar outro consumidor real utilizável. Para manipulação de resultado obsoleto, entregue uma conclusão antiga após o proprietário ter mudado. Use fixtures existentes e sincronização orientada a eventos; sleeps arbitrários e retentativas extras não estabelecem essas condições.
Valide e Finalize
Termine as edições relevantes de código-fonte/teste antes de iniciar sua execução de teste. Mantenha o checkout estável durante essa execução.
- Execute o teste ou módulo focado, por exemplo
cargo test -p <crate> <test_filter>. Use o alvo e a plataforma que realmente o possuem; os testes de desktop estão no alvo bináriooxideterm-nativedeoxideterm-gpui-app. O agente remoto independente usa--manifest-path agent/Cargo.toml. - Leia o resultado e verifique se os testes pretendidos realmente foram executados. Um comando bem-sucedido com zero testes correspondentes não é prova. Após uma remoção ou movimentação, execute a cobertura restante nomeada e qualquer verificação de integração afetada distinta.
- Execute
cargo fmt --checkegit diff --checkpara edições Rust. Adicione verificações de crate, testes de script, auditoria de localidade ou workflows manuais de acordo com a matriz de verificação. Reutilize resultados até que alterações relevantes ou novas evidências os invalidem. - Revise o diff final e o status. Verifique se nenhum comportamento único desapareceu, nenhuma asserção foi enfraquecida para esconder uma falha de produto e nenhum trabalho não relacionado foi alterado.
Use mutação deliberada apenas quando necessário para resolver uma dúvida concreta sobre uma asserção. Mantenha-a isolada do trabalho do usuário, restaure o código-fonte exato depois e não a exija para cada teste. Auditorias de subsistema devem reconciliar os casos removidos com seus testes restantes nomeados antes de executar as suítes afetadas finais.
Relate a decisão, o comportamento ainda protegido, as verificações realmente executadas e qualquer limite não verificado material. Explique a cobertura removida quando a exclusão ocorreu. Pare quando o escopo solicitado estiver completo; não amplie a auditoria para atender um alvo de contagem ou redução.
Fonte
Adaptado dos princípios de valor de teste e evidência em test-audit e campaign guidance do OpenClaw. Execução, propriedade e validação aqui seguem as regras do repositório OxideTerm.