openclaw-testing

OpenClaw Testing

Política de prova

• PR CI = prova ampla padrão. Mudanças compilam + testes focados passam → PR pronto para abrir. A CI executa suítes amplas; nunca atrase o PR por execuções de suíte pré-PR.

• Build indisponível antes da publicação: quando a publicação já está autorizada, a capacidade remota está indisponível e a execução local não é qualificada, envie/abra um PR rascunho com o build exato faltante e a lacuna de capacidade registrada. Diferencie esse build para a CI exata do cabeçalho. Exija seu sucesso antes de marcar como pronto ou mesclar. Isso altera apenas o momento da prova, não a autoridade de publicação, confiança na fonte, credenciais, aprovação do proprietário ou portões de merge. A CI automática pula rascunhos. Para uma branch canônica confiável, use o envio manual existente de ci.yml com target_ref definido para o SHA completo do cabeçalho enviado (ghx workflow run ci.yml --repo openclaw/openclaw --ref main -f target_ref=<sha>). Verifique se o SHA de checkout selecionado e o job build-artifacts bem-sucedido cobrem o build necessário. A CI build:ci-artifacts omite a emissão de declaração completa. Mantenha a prova descoberta pendente. Um job ignorado ou SHA de referência de workflow não é prova de build. Vincule a execução no PR e, em seguida, use os portões normais de PR pronto e landing. Fonte não confiável mantém sua rota sem segredos.

• Antes do PR, prove de forma restrita: testes tocados com pnpm test <arquivo> --maxWorkers=1, typecheck direcionado, lint, format. Prefira prova local para trabalho confiável e delimitado quando dependências e capacidade do host atual são qualificadas. A execução local é opcional: um comando focado ainda pode carregar um grande grafo do compilador ou expandir para lanes amplas.

• Escolha prova remota deliberadamente. Use PR CI para prova ampla; Crabbox/Testbox podem cobrir verificações caras, um host local ocupado ou não qualificado, outro SO/dispositivo, provedores/canais ao vivo, E2E longo ou benchmarks pesados. Adquira apenas quando o comando estiver pronto e a capacidade for concedida prontamente. Se estiver na fila, pare apenas a alocação de propriedade da tarefa; use PR CI ou um escopo local seguro. Mantenha prova específica de plataforma descoberta pendente. Nunca force trabalho pesado em uma máquina ocupada ou encadeie provedores. Use o menor perfil comprovado para a carga de trabalho selecionada.

• Nunca reexecute ou reenvie apenas para ficar verde. Corrija falhas reais; leia a classificação de falhas da CI disponível antes de atribuir o vermelho.

• Prove contrato alterado, complete portões obrigatórios, termine. Amplie/repita apenas para entradas alteradas, falhas ou risco nomeado não resolvido.

• Siga AGENTS.md com escopo; criação/revisão de testes: use guia de fronteira e test-audit.

Selecione a prova

• Selecione prova para contrato tocado; reutilize prova válida (reexecute para entradas alteradas ou cobertura faltante); termine os portões obrigatórios do workflow dentro dos limites do usuário/host; relate verificações não executadas e lacunas. Prove comportamento visível ao usuário através do fluxo real quando viável; APIs externas precisam de prova de contrato ao vivo; harness isolado mock-Gateway = prova de fronteira de canal válida. Apenas documentação: sanity de docs e git diff --check.

• Defeito em tempo de execução: reproduza ponto de entrada real; reexecute-o + irmãos relevantes.

• Fonte confiável: pnpm changed:lanes --json, testes focados + typecheck/lint/format direcionados; pnpm check:changed = verificação local inteligente opcional.

• Contrato público SDK/plugin: consumidores representativos, não varredura de todos os plugins.

• Saída de build, imports lazy, limites de pacotes: inclua pnpm build ou o build CI do repositório que cobre o contrato alterado. Registre requisitos de empacotamento/plataforma/declaração descobertos. Builds completos de pacote ou release ainda precisam de sua prova correspondente.

• Workflow: git diff --check + pnpm check:workflows.

• Apenas documentação: verificações relevantes de docs/links/format + git diff --check; sem testes em tempo de execução.

• Leia sob demanda: comandos locais, Crabbox, configuração remota OpenClaw, prova de pacote/Docker, CI de release, matriz de release de plugin, autoria Docker, skill de canal/ Control UI E2E.

• Um harness isolado mock-Gateway é prova de fronteira de canal válida; declare lacunas ao vivo. Prove comportamento visível ao usuário através do fluxo real quando viável; APIs externas exigem prova de contrato ao vivo. Leia o guia de canal/plataforma com escopo para trabalho de canal ao vivo ou aplicativo nativo. Alegações do Telegram exigem prova de userbot do Test Server com credenciais Convex-leased. Alegações de plataforma exigem evidência em dispositivo real; prova de permissão macOS exige um aplicativo assinado estável.

• Prova de release: preserve SHAs de candidato/Tooling; nunca conceda autoridade de publicação.

Fonte e limites de estado

• Nunca execute código, wrappers ou configuração de contribuidor/ fork não confiável localmente. Use CI de fork sem segredos ou AWS direta sanitizada através de Crabbox; nunca Testbox hidratado com credenciais. Execução com credenciais: aprovação do mantenedor após revisão necessária; nunca hidrate lease não confiável.
• Estado isolado + porta livre. Nunca reinicie, edite ou teste Gateway/operador/dados reais sem aprovação explícita por tarefa. Preserve processos não relacionados e instalações de dependências compartilhadas.
• Comandos de teste/verificação concorrentes: separe valores de OPENCLAW_VITEST_FS_MODULE_CACHE_PATH ou execute serialmente; verificações também podem executar Vitest. Apenas wrappers do repositório, nunca Vitest bruto. Worktrees vinculados preparados: node scripts/run-vitest.mjs <arquivo> --maxWorkers=1 evita reconciliação de pnpm; PR CI executa as verificações amplas.

Falhas de CI

• PR CI falha → pnpm test:ci-failed <pr>; leia classificação pré-existente/nova/desconhecida.
• Corrija novas falhas; investigue desconhecido → pnpm test:ci-failed <pr> --run até que os testes selecionados passem localmente → envie uma vez.
• --run habilita OPENCLAW_NODE_TEST_PLAN_CONTINUE_ON_FAILURE=1: colete falhas comuns em todas as configurações selecionadas, enquanto falhas de infraestrutura ainda param; use o mesmo opt-in para reexecuções focadas manuais.
• Falhas pré-existentes: regra de landing de tabela de falhas. Assinaturas correspondentes ≠ atribuição apenas por nome de job.
• Nunca gh run rerun para perseguir o verde; nunca suíte completa local para reparo de CI.
• Vincule diagnóstico a SHA + job exatos. Busque logs de falha uma vez; prefira estado exato de execução/job sobre resumos de PR desatualizados.
• Distinga produto, harness, infraestrutura, credenciais, cancelamento de execução substituída. Snapshots passam no macOS/falham na CI: reproduza bytes Linux/Node antes de regenerar.

Exceções de baseline e expected-failure

Exceções restritas de baseline, snapshot, ignorar e expected-failure são decisões do implementador apenas quando cada entrada é verificada em relação à fonte e o PR registra seu motivo (por exemplo, metadados de propriedade da ferramenta em um snapshot de atualização enquanto os dados do usuário permanecem exatos). Nunca mascare uma regressão real ou alteração de dados do usuário. Exceções genéricas ou não verificadas precisam de aprovação. Atualizações de catraca de redução exata são manutenção. Um PR de correção pode adicionar um registro separado rastreado config/test-lines-allocations/<mudança>.txt para exatamente sua própria regressão justificada de linhas de teste líquidas quando o corpo do squash declarar o motivo. Mantenha o escalar compartilhado inalterado para que concessões independentes sejam mescladas. O verificador limita o crescimento efetivo do teto em relação ao crescimento real de LF e preserva a dívida herdada. Outros aumentos, incluindo reconciliação apenas de escalar, precisam de aprovação. Veja o orçamento de custo para formato de registro e poda.

Para mocks de módulo, siga o contrato de fixture. Quando uma anotação de isolamento aposenta uma entrada de baseline existente, confirme a anotação e a remoção de baseline correspondente juntos. Inspecione o diff completo de baseline porque --prune varre todo o checkout. Verifique o baseline atualizado com uma execução de guarda sem --prune.

Política de falha de teste

• Falhas = defeitos. Tentativa de reprodução limitada (primeiro na mesma ordem de shard); identifique proprietário; corrija produto, fixture, estado compartilhado, bugs de ordenação.
• Correção comprovada: adicione regressão; cite a correção de outro proprietário quando aplicável.
• Correção segura não pode ser estabelecida/completada: registre falha original, tentativas, evidência, incerteza no PR; continue sob portões normais de CI/revisão.
• Falha não resolvida sozinha não bloqueia landing nem requer aprovação extra. Reexecução bem-sucedida ≠ correção comprovada.
• Nunca esconda falhas com repetições, timeouts mais longos, asserções mais fracas, mocks mais amplos, baselines alterados.