Skip to main content
Riferimento per utility, pattern e applicazione del lint per i Plugin di OpenClaw.
Si cercano esempi di test? Le guide pratiche includono esempi di test completi: Test dei Plugin per canali e Test dei Plugin per provider.

Utility di test

Questi sottopercorsi sono punti di ingresso del codice sorgente locali al repository per i test dei Plugin inclusi in OpenClaw. Non sono esportazioni package.json pubblicate per Plugin di terze parti e possono importare Vitest o altre dipendenze di test disponibili solo nel repository.
Usare questi sottopercorsi specifici per i test dei Plugin inclusi. Il precedente barrel openclaw/plugin-sdk/testing era locale al repository, escluso dai pacchetti distribuiti ed è stato rimosso. L’alias legacy openclaw/plugin-sdk/test-utils rimane locale al repository; pnpm run lint:plugins:no-extension-test-core-imports (scripts/check-no-extension-test-core-imports.ts) rifiuta le nuove importazioni di tale alias nei test delle estensioni.

Esportazioni disponibili

Le suite di contratti dei plugin inclusi utilizzano inoltre questi sottopercorsi di test dell’SDK per gli helper di fixture di registro, manifest, artefatti pubblici e runtime riservati ai test. Le suite riservate al core che dipendono dall’inventario OpenClaw incluso rimangono invece in src/plugins/contracts.

Tipi

I sottopercorsi di test mirati riesportano anche tipi utili nei file di test:

Test della risoluzione della destinazione

Usare installCommonResolveTargetErrorCases per aggiungere i casi di errore standard per la risoluzione della destinazione del canale:

Modelli di test

Test dei contratti di registrazione

Gli unit test che passano un mock api scritto manualmente a register(api) non esercitano i controlli di accettazione del loader di OpenClaw. Aggiungere almeno uno smoke test basato sul loader per ogni superficie di registrazione da cui dipende il Plugin, in particolare gli hook e le funzionalità esclusive come la memoria. Il loader reale non riesce a registrare il Plugin quando mancano i metadati obbligatori o un Plugin chiama un’API di una funzionalità che non gli appartiene. Ad esempio, api.registerHook(...) richiede un nome di hook e api.registerMemoryCapability(...) richiede che il manifesto del Plugin o la voce esportata dichiari kind: "memory".

Test dell’accesso alla configurazione in fase di esecuzione

Preferire il mock condiviso del runtime del Plugin fornito da openclaw/plugin-sdk/plugin-test-runtime. I relativi mock runtime.config.loadConfig() e runtime.config.writeConfigFile(...) generano un errore per impostazione predefinita, affinché i test rilevino nuovi utilizzi delle API di compatibilità deprecate. Sovrascrivere questi mock solo quando il test verifica esplicitamente il comportamento di compatibilità legacy.

Unit test di un Plugin di canale

Unit test di un Plugin provider

Simulazione del runtime del Plugin

Per il codice che usa createPluginRuntimeStore, simulare il runtime nei test:

Test con stub per istanza

Preferire gli stub per istanza alla modifica del prototipo:

Test dei contratti (Plugin nel repository)

I Plugin inclusi dispongono di test dei contratti che verificano la titolarità della registrazione:
Questi test verificano:
  • Quali Plugin registrano quali provider
  • Quali Plugin registrano quali provider vocali
  • Correttezza della struttura di registrazione
  • Conformità al contratto del runtime

Esecuzione di test circoscritti

Per un Plugin specifico:
Solo per i test dei contratti:

Applicazione delle regole di lint (Plugin nel repository)

scripts/run-additional-boundary-checks.mjs esegue in CI una serie di controlli lint:plugins:* sui confini delle importazioni; ciascuno può essere eseguito anche autonomamente in locale: I Plugin esterni non sono soggetti a queste regole di lint, ma è consigliabile seguire gli stessi modelli.

Configurazione dei test

OpenClaw usa Vitest 4 con report informativi sulla copertura V8. Per i test dei Plugin:
Se le esecuzioni locali causano un’elevata pressione sulla memoria:

Risorse correlate