Skip to main content
Referenz für Testhilfsprogramme, Muster und Lint-Durchsetzung für OpenClaw- Plugins.
Suchen Sie nach Testbeispielen? Die Anleitungen enthalten ausgearbeitete Testbeispiele: Tests für Channel-Plugins und Tests für Provider-Plugins.

Testhilfsprogramme

Diese Unterpfade sind repo-lokale Quell-Einstiegspunkte für die mitgelieferten Plugin-Tests von OpenClaw. Sie sind keine veröffentlichten package.json-Exporte für Drittanbieter- Plugins und können Vitest oder andere ausschließlich im Repository verfügbare Testabhängigkeiten importieren.
Verwenden Sie diese gezielten Unterpfade für Tests mitgelieferter Plugins. Das frühere openclaw/plugin-sdk/testing-Barrel war repo-lokal, von ausgelieferten Paketen ausgeschlossen und wurde entfernt. Der frühere Alias openclaw/plugin-sdk/test-utils wurde zusammen damit entfernt. pnpm run lint:plugins:no-extension-test-core-imports (scripts/check-no-extension-test-core-imports.ts) hält Erweiterungstests auf den oben genannten gezielten Test-Unterpfaden.

Verfügbare Exporte

Gebündelte Plugin-Vertragssuiten verwenden diese SDK-Testunterpfade außerdem für reine Testhilfen für Registry, Manifest, öffentliche Artefakte und Runtime-Fixtures. Nur für den Core bestimmte Suiten, die vom gebündelten OpenClaw-Inventar abhängen, verbleiben stattdessen unter src/plugins/contracts.

Typen

Spezifische Testunterpfade re-exportieren außerdem Typen, die in Testdateien nützlich sind:

Auflösung von Testzielen

Verwenden Sie installCommonResolveTargetErrorCases, um Standardfehlerfälle für die Auflösung von Kanalzielen hinzuzufügen:

Testmuster

Testen von Registrierungsverträgen

Unit-Tests, die einen manuell erstellten api-Mock an register(api) übergeben, prüfen die Akzeptanzprüfungen des OpenClaw-Loaders nicht. Fügen Sie mindestens einen Loader-gestützten Smoke-Test für jede Registrierungsoberfläche hinzu, von der Ihr Plugin abhängt, insbesondere für Hooks und exklusive Fähigkeiten wie Memory. Der tatsächliche Loader lässt die Plugin-Registrierung fehlschlagen, wenn erforderliche Metadaten fehlen oder ein Plugin eine Capability-API aufruft, die ihm nicht gehört. Beispielsweise erfordert api.registerHook(...) einen Hook-Namen, und api.registerMemoryCapability(...) erfordert, dass das Plugin-Manifest oder der exportierte Einstiegspunkt kind: "memory" deklariert.

Testen des Zugriffs auf die Runtime-Konfiguration

Bevorzugen Sie den gemeinsamen Plugin-Runtime-Mock aus openclaw/plugin-sdk/plugin-test-runtime. Seine Hilfsfunktionen für die Runtime-Konfiguration bilden die aktuellen Snapshot- und Mutations-APIs ab.

Unit-Test eines Kanal-Plugins

Unit-Test eines Provider-Plugins

Mocking der Plugin-Runtime

Für Code, der createPluginRuntimeStore verwendet, mocken Sie die Runtime in Tests:

Testen mit instanzbezogenen Stubs

Bevorzugen Sie instanzbezogene Stubs gegenüber der Mutation des Prototyps:

Vertragstests (Plugins im Repository)

Gebündelte Plugins verfügen über Vertragstests, die die Eigentümerschaft der Registrierung überprüfen:
Diese Tests prüfen:
  • Welche Plugins welche Provider registrieren
  • Welche Plugins welche Sprachanbieter registrieren
  • Korrektheit der Registrierungsstruktur
  • Einhaltung des Runtime-Vertrags

Ausführen eingegrenzter Tests

Für ein bestimmtes Plugin:
Nur für Vertragstests:

Lint-Durchsetzung (Plugins im Repository)

scripts/run-additional-boundary-checks.mjs führt in der CI eine Reihe von lint:plugins:*- Prüfungen der Importgrenzen aus; jede davon kann auch lokal eigenständig ausgeführt werden: Externe Plugins unterliegen diesen Lint-Regeln nicht, es wird jedoch empfohlen, dieselben Muster zu befolgen.

Testkonfiguration

OpenClaw verwendet Vitest 4 mit informativen V8-Coverage-Berichten. Für Plugin-Tests:
Wenn lokale Ausführungen zu hoher Speicherauslastung führen:

Verwandte Themen