Skip to main content
Referência para utilitários, padrões e aplicação de lint em testes de plugins do OpenClaw.
Procurando exemplos de testes? Os guias de instruções incluem exemplos práticos de testes: Testes de plugins de canal e Testes de plugins de provedor.

Utilitários de teste

Estes subcaminhos são pontos de entrada de código-fonte locais do repositório para os testes dos plugins incluídos no próprio OpenClaw. Eles não são exports package.json publicados para plugins de terceiros e podem importar o Vitest ou outras dependências de teste exclusivas do repositório.
Use estes subcaminhos específicos para testes de plugins incluídos. O barrel openclaw/plugin-sdk/testing anterior era local do repositório, foi excluído dos pacotes distribuídos e foi removido. O alias legado openclaw/plugin-sdk/test-utils permanece local do repositório; pnpm run lint:plugins:no-extension-test-core-imports (scripts/check-no-extension-test-core-imports.ts) rejeita novas importações desse alias em testes de extensões.

Exports disponíveis

Os conjuntos de contratos de plugins integrados também usam esses subcaminhos de teste do SDK para auxiliares de fixtures de registro, manifesto, artefatos públicos e runtime exclusivos de teste. Os conjuntos exclusivos do núcleo que dependem do inventário integrado do OpenClaw permanecem em src/plugins/contracts.

Tipos

Subcaminhos de teste específicos também reexportam tipos úteis em arquivos de teste:

Teste da resolução de destinos

Use installCommonResolveTargetErrorCases para adicionar casos de erro padrão para a resolução de destinos do canal:

Padrões de teste

Teste de contratos de registro

Testes de unidade que passam um mock api escrito manualmente para register(api) não exercitam as verificações de aceitação do carregador do OpenClaw. Adicione pelo menos um teste de fumaça apoiado pelo carregador para cada superfície de registro da qual seu plugin depende, especialmente hooks e recursos exclusivos, como memória. O carregador real causa falha no registro do plugin quando os metadados obrigatórios estão ausentes ou um plugin chama uma API de recurso que não possui. Por exemplo, api.registerHook(...) exige um nome de hook, e api.registerMemoryCapability(...) exige que o manifesto do plugin ou a entrada exportada declare kind: "memory".

Teste do acesso à configuração do runtime

Prefira o mock compartilhado do runtime do plugin de openclaw/plugin-sdk/plugin-test-runtime. Seus mocks runtime.config.loadConfig() e runtime.config.writeConfigFile(...) lançam erros por padrão para que os testes detectem novos usos de APIs de compatibilidade obsoletas. Substitua esses mocks somente quando o teste estiver cobrindo explicitamente o comportamento de compatibilidade legada.

Teste de unidade de um plugin de canal

Teste de unidade de um plugin de provedor

Simulação do runtime do plugin

Para código que usa createPluginRuntimeStore, simule o runtime nos testes:

Teste com stubs por instância

Prefira stubs por instância em vez de mutação do protótipo:

Testes de contrato (plugins no repositório)

Plugins integrados têm testes de contrato que verificam a propriedade do registro:
Esses testes verificam:
  • Quais plugins registram quais provedores
  • Quais plugins registram quais provedores de voz
  • Correção da estrutura de registro
  • Conformidade com o contrato do runtime

Execução de testes com escopo

Para um plugin específico:
Somente para testes de contrato:

Aplicação de lint (plugins no repositório)

scripts/run-additional-boundary-checks.mjs executa um conjunto de verificações de limite de importação lint:plugins:* na CI; cada uma também pode ser executada localmente de forma independente: Plugins externos não estão sujeitos a essas regras de lint, mas é recomendável seguir os mesmos padrões.

Configuração de testes

O OpenClaw usa o Vitest 4 com relatórios informativos de cobertura V8. Para testes de plugins:
Se as execuções locais causarem pressão de memória:

Relacionados