Tests

• Komplettes Test-Kit (Suites, Live, Docker): Tests

• Validierung von Updates und Plugin-Paketen: Updates und Plugins testen

• Routinemäßige lokale Testreihenfolge:

  1. pnpm test:changed für geänderten Vitest-Nachweis im Änderungsumfang.
  2. pnpm test <path-or-filter> für eine Datei, ein Verzeichnis oder ein explizites Ziel.
  3. pnpm test nur, wenn Sie bewusst die vollständige lokale Vitest-Suite benötigen.

• pnpm test:force: Beendet jeden verbliebenen Gateway-Prozess, der den Standard-Kontrollport belegt, und führt dann die vollständige Vitest-Suite mit einem isolierten Gateway-Port aus, damit Server-Tests nicht mit einer laufenden Instanz kollidieren. Verwenden Sie dies, wenn ein vorheriger Gateway-Lauf Port 18789 belegt gelassen hat.

• pnpm test:coverage: Führt die Unit-Suite mit V8-Abdeckung aus (über vitest.unit.config.ts). Dies ist ein Abdeckungs-Gate für die Standard-Unit-Lane, keine vollständige All-File-Abdeckung für das gesamte Repository. Die Schwellenwerte liegen bei 70 % für Zeilen/Funktionen/Anweisungen und 55 % für Branches. Da coverage.all false ist und die Standard-Lane die Abdeckung auf nicht schnelle Unit-Tests mit benachbarten Quelldateien beschränkt, misst das Gate den von dieser Lane verantworteten Quellcode statt jedes transitiven Imports, den sie zufällig lädt.

• pnpm test:coverage:changed: Führt Unit-Abdeckung nur für Dateien aus, die seit origin/main geändert wurden.

• pnpm test:changed: günstiger, intelligenter geänderter Testlauf. Er führt präzise Ziele aus direkten Teständerungen, benachbarten *.test.ts-Dateien, expliziten Quellzuordnungen und dem lokalen Importgraphen aus. Breite Konfigurations-/Paketänderungen werden übersprungen, sofern sie nicht präzisen Tests zugeordnet werden können.

• OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed: explizit breiter geänderter Testlauf. Verwenden Sie dies, wenn eine Änderung an Test-Harness/Konfiguration/Paket auf das breitere geänderte Testverhalten von Vitest zurückfallen soll.

• pnpm changed:lanes: zeigt die durch den Diff gegen origin/main ausgelösten Architektur-Lanes an.

• pnpm check:changed: delegiert außerhalb von CI standardmäßig an Crabbox/Testbox und führt dann das intelligente geänderte Check-Gate für den Diff gegen origin/main im Remote-Child aus. Es führt Typecheck-, Lint- und Guard-Befehle für die betroffenen Architektur-Lanes aus, aber keine Vitest-Tests. Verwenden Sie pnpm test:changed oder explizit pnpm test <target> als Testnachweis.

• Codex-Worktrees und verlinkte/sparse Checkouts: Vermeiden Sie direkte lokale pnpm test*, pnpm check* und pnpm crabbox:run, sofern Sie nicht verifiziert haben, dass pnpm keine Abhängigkeiten abgleicht. Für winzige Nachweise mit expliziter Datei verwenden Sie node scripts/run-vitest.mjs <path-or-filter>; für geänderte Gates oder breiten Nachweis verwenden Sie node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox ... -- env OPENCLAW_CHECK_CHANGED_REMOTE_CHILD=1 OPENCLAW_CHANGED_LANES_RAW_SYNC=1 corepack pnpm check:changed, damit pnpm innerhalb von Testbox läuft.

• Testbox-über-Crabbox-Nachweis: Verwenden Sie den finalen exitCode des Wrappers und das Timing-JSON als Befehlsergebnis. Der delegierte Blacksmith-GitHub-Actions-Lauf kann nach einem erfolgreichen SSH-Befehl cancelled anzeigen, weil die Testbox von außerhalb der Keepalive-Action gestoppt wird; prüfen Sie die Wrapper-Zusammenfassung und die Befehlsausgabe, bevor Sie dies als Testfehler behandeln.

• OPENCLAW_HEAVY_CHECK_LOCK_SCOPE=worktree <local-heavy-check command>: hält die Serialisierung schwerer Checks für Befehle wie pnpm check:changed und gezielte pnpm test ... innerhalb des aktuellen Worktrees statt im gemeinsamen Git-Verzeichnis. Verwenden Sie dies nur auf leistungsstarken lokalen Hosts, wenn Sie bewusst unabhängige Checks über verlinkte Worktrees hinweg ausführen.

• pnpm test: leitet explizite Datei-/Verzeichnisziele durch bereichsbezogene Vitest-Lanes. Läufe ohne Ziel sind Full-Suite-Nachweise: Sie verwenden feste Shard-Gruppen, expandieren für lokale parallele Ausführung zu Leaf-Konfigurationen und geben den erwarteten lokalen Shard-Fanout vor dem Start aus. Die Erweiterungsgruppe expandiert immer zu den Shard-Konfigurationen pro Erweiterung statt zu einem einzigen riesigen Root-Projektprozess.

• Test-Wrapper-Läufe enden mit einer kurzen Zusammenfassung [test] passed|failed|skipped ... in .... Vitests eigene Dauerzeile bleibt das Detail pro Shard.

• Gemeinsamer OpenClaw-Testzustand: Verwenden Sie src/test-utils/openclaw-test-state.ts aus Vitest, wenn ein Test ein isoliertes HOME, OPENCLAW_STATE_DIR, OPENCLAW_CONFIG_PATH, eine Konfigurations-Fixture, einen Workspace, ein Agent-Verzeichnis oder einen Auth-Profile-Speicher benötigt.

• pnpm test:env-mutations:report: nicht blockierender Bericht über Tests und Harnesses, die HOME, OPENCLAW_STATE_DIR, OPENCLAW_CONFIG_PATH, OPENCLAW_WORKSPACE_DIR oder verwandte OpenClaw-Env-Schlüssel direkt verändern. Verwenden Sie ihn, um Kandidaten für die Migration zum gemeinsamen Test-State-Helfer zu finden.

• Gemocktes Control-UI-E2E: Verwenden Sie pnpm test:ui:e2e für die Vitest-+Playwright-Lane, die die Vite Control UI startet und eine echte Chromium-Seite gegen einen gemockten Gateway-WebSocket steuert. Tests liegen in ui/src/**/*.e2e.test.ts; gemeinsame Mocks und Steuerungen liegen in ui/src/test-helpers/control-ui-e2e.ts. pnpm test:e2e enthält diese Lane. In Codex-Worktrees bevorzugen Sie node scripts/run-vitest.mjs run --config test/vitest/vitest.ui-e2e.config.ts --configLoader runner ui/src/ui/e2e/chat-flow.e2e.test.ts für winzige gezielte Nachweise, nachdem Abhängigkeiten installiert sind, oder Testbox/Crabbox für breiteren GUI-Nachweis.

• Prozess-E2E-Helfer: Verwenden Sie test/helpers/openclaw-test-instance.ts, wenn ein Vitest-Prozess-Level-E2E-Test einen laufenden Gateway, eine CLI-Umgebung, Log-Erfassung und Cleanup an einer Stelle benötigt.

• TUI-PTY-Tests: Verwenden Sie node scripts/run-vitest.mjs run --config test/vitest/vitest.tui-pty.config.ts für die schnelle Fake-Backend-PTY-Lane. Verwenden Sie OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 oder pnpm tui:pty:test:watch --mode local für den langsameren tui --local-Smoke, der nur den externen Modellendpunkt mockt. Prüfen Sie stabilen sichtbaren Text oder Fixture-Aufrufe, keine rohen ANSI-Snapshots.

• Docker-/Bash-E2E-Helfer: Lanes, die scripts/lib/docker-e2e-image.sh sourcen, können docker_e2e_test_state_shell_b64 <label> <scenario> in den Container übergeben und mit scripts/lib/openclaw-e2e-instance.sh dekodieren; Multi-Home-Skripte können docker_e2e_test_state_function_b64 übergeben und in jedem Flow openclaw_test_state_create <label> <scenario> aufrufen. Low-Level-Aufrufer können scripts/lib/openclaw-test-state.mjs shell --label <name> --scenario <name> für ein Shell-Snippet im Container verwenden oder node scripts/lib/openclaw-test-state.mjs -- create --label <name> --scenario <name> --env-file <path> --json für eine sourcebare Host-Env-Datei. Das -- vor create verhindert, dass neuere Node-Runtimes --env-file als Node-Flag behandeln. Docker-/Bash-Lanes, die einen Gateway starten, können scripts/lib/openclaw-e2e-instance.sh im Container sourcen für Entrypoint-Auflösung, gemockten OpenAI-Start, Gateway-Start im Vordergrund/Hintergrund, Readiness-Probes, State-Env-Export, Log-Dumps und Prozess-Cleanup.

• Full-, Extension- und Include-Pattern-Shard-Läufe aktualisieren lokale Timing-Daten in .artifacts/vitest-shard-timings.json; spätere Whole-Config-Läufe verwenden diese Timings, um langsame und schnelle Shards auszubalancieren. Include-Pattern-CI-Shards hängen den Shard-Namen an den Timing-Schlüssel an, wodurch gefilterte Shard-Timings sichtbar bleiben, ohne Whole-Config-Timing-Daten zu ersetzen. Setzen Sie OPENCLAW_TEST_PROJECTS_TIMINGS=0, um das lokale Timing-Artefakt zu ignorieren.

• Ausgewählte plugin-sdk- und commands-Testdateien laufen jetzt über dedizierte leichte Lanes, die nur test/setup.ts behalten und laufzeitlastige Fälle auf ihren vorhandenen Lanes belassen.

• Quelldateien mit benachbarten Tests werden diesem benachbarten Test zugeordnet, bevor auf breitere Verzeichnis-Globs zurückgefallen wird. Helferänderungen unter src/channels/plugins/contracts/test-helpers, src/plugin-sdk/test-helpers und src/plugins/contracts verwenden einen lokalen Importgraphen, um importierende Tests auszuführen, statt jeden Shard breit laufen zu lassen, wenn der Abhängigkeitspfad präzise ist.

• auto-reply teilt sich jetzt außerdem in drei dedizierte Konfigurationen (core, top-level, reply) auf, damit das Reply-Harness die leichteren Top-Level-Status-/Token-/Helfer-Tests nicht dominiert.

• Die Basis-Vitest-Konfiguration setzt jetzt standardmäßig pool: "threads" und isolate: false, wobei der gemeinsame nicht isolierte Runner über die Repository-Konfigurationen hinweg aktiviert ist.

• pnpm test:channels führt vitest.channels.config.ts aus.

• pnpm test:extensions und pnpm test extensions führen alle Erweiterungs-/Plugin-Shards aus. Schwere Channel-Plugins, das Browser-Plugin und OpenAI laufen als dedizierte Shards; andere Plugin-Gruppen bleiben gebündelt. Verwenden Sie pnpm test extensions/<id> für eine gebündelte Plugin-Lane.

• pnpm test:perf:imports: aktiviert Vitest-Berichte zu Importdauer und Importaufschlüsselung, während für explizite Datei-/Verzeichnisziele weiterhin bereichsbezogenes Lane-Routing verwendet wird.

• pnpm test:perf:imports:changed: dasselbe Import-Profiling, aber nur für Dateien, die seit origin/main geändert wurden.

• pnpm test:perf:changed:bench -- --ref <git-ref> benchmarked den gerouteten Changed-Mode-Pfad gegen den nativen Root-Projektlauf für denselben committeten Git-Diff.

• pnpm test:perf:changed:bench -- --worktree benchmarked die aktuelle Worktree-Änderungsmenge, ohne vorher zu committen.

• pnpm test:perf:profile:main: schreibt ein CPU-Profil für den Vitest-Main-Thread (.artifacts/vitest-main-profile).

• pnpm test:perf:profile:runner: schreibt CPU- und Heap-Profile für den Unit-Runner (.artifacts/vitest-runner-profile).

• pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json: führt jede Full-Suite-Vitest-Leaf-Konfiguration seriell aus und schreibt gruppierte Dauerdaten sowie JSON-/Log-Artefakte pro Konfiguration. Der Test Performance Agent verwendet dies als Baseline, bevor er Slow-Test-Fixes versucht.

• pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json: vergleicht gruppierte Berichte nach einer performanceorientierten Änderung.

• pnpm test:docker:timings <summary.json> untersucht langsame Docker-Lanes nach einem Docker-All-Lauf; verwenden Sie pnpm test:docker:rerun <run-id|summary.json|failures.json>, um günstige gezielte Rerun-Befehle aus denselben Artefakten auszugeben.

• Gateway-Integration: Opt-in über OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test oder pnpm test:gateway.

• pnpm test:e2e: Führt das Repository-E2E-Aggregat aus: Gateway-End-to-End-Smoke-Tests plus die gemockte Browser-E2E-Lane der Control UI.

• pnpm test:e2e:gateway: Führt Gateway-End-to-End-Smoke-Tests aus (Multi-Instance-WS/HTTP/Node-Pairing). Standardmäßig threads + isolate: false mit adaptiven Workern in vitest.e2e.config.ts; passen Sie dies mit OPENCLAW_E2E_WORKERS=<n> an und setzen Sie OPENCLAW_E2E_VERBOSE=1 für ausführliche Logs.

• pnpm test:live: Führt Provider-Live-Tests aus (minimax/zai). Erfordert API-Schlüssel und LIVE=1 (oder provider-spezifisch *_LIVE_TEST=1), um sie nicht zu überspringen.

• pnpm test:docker:all: Erstellt das gemeinsame Live-Test-Image, packt OpenClaw einmal als npm-Tarball, erstellt oder verwendet ein minimales Node/Git-Runner-Image sowie ein funktionales Image, das diesen Tarball nach /app installiert, und führt dann Docker-Smoke-Lanes mit OPENCLAW_SKIP_DOCKER_BUILD=1 über einen gewichteten Scheduler aus. Das minimale Image (OPENCLAW_DOCKER_E2E_BARE_IMAGE) wird für Installer-/Update-/Plugin-Abhängigkeits-Lanes verwendet; diese Lanes mounten den vorab erstellten Tarball, statt kopierte Repo-Quellen zu verwenden. Das funktionale Image (OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE) wird für normale Built-App-Funktions-Lanes verwendet. scripts/package-openclaw-for-docker.mjs ist der einzige lokale/CI-Package-Packer und validiert den Tarball sowie dist/postinstall-inventory.json, bevor Docker ihn verwendet. Docker-Lane-Definitionen befinden sich in scripts/lib/docker-e2e-scenarios.mjs; die Planner-Logik befindet sich in scripts/lib/docker-e2e-plan.mjs; scripts/test-docker-all.mjs führt den ausgewählten Plan aus. node scripts/test-docker-all.mjs --plan-json gibt den Scheduler-eigenen CI-Plan für ausgewählte Lanes, Image-Arten, Package-/Live-Image-Anforderungen, State-Szenarien und Zugangsdatenprüfungen aus, ohne Docker zu bauen oder auszuführen. OPENCLAW_DOCKER_ALL_PARALLELISM=<n> steuert Prozess-Slots und ist standardmäßig 10; OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n> steuert den Provider-sensitiven Tail-Pool und ist standardmäßig 10. Caps für schwere Lanes sind standardmäßig OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9, OPENCLAW_DOCKER_ALL_NPM_LIMIT=5 und OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7; Provider-Caps sind standardmäßig auf eine schwere Lane pro Provider gesetzt über OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4, OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4 und OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4. Verwenden Sie OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT oder OPENCLAW_DOCKER_ALL_DOCKER_LIMIT für größere Hosts. Wenn eine Lane auf einem Host mit niedriger Parallelität das effektive Gewicht oder Ressourcen-Cap überschreitet, kann sie dennoch aus einem leeren Pool starten und allein laufen, bis sie Kapazität freigibt. Lane-Starts werden standardmäßig um 2 Sekunden gestaffelt, um lokale Erstellungsanstürme des Docker-Daemons zu vermeiden; überschreiben Sie dies mit OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>. Der Runner führt standardmäßig Docker-Preflights aus, bereinigt veraltete OpenClaw-E2E-Container, gibt alle 30 Sekunden den Status aktiver Lanes aus, teilt Provider-CLI-Tool-Caches zwischen kompatiblen Lanes, wiederholt vorübergehende Live-Provider-Fehler standardmäßig einmal (OPENCLAW_DOCKER_ALL_LIVE_RETRIES=<n>) und speichert Lane-Zeiten in .artifacts/docker-tests/lane-timings.json für eine längste-zuerst-Sortierung in späteren Läufen. Verwenden Sie OPENCLAW_DOCKER_ALL_DRY_RUN=1, um das Lane-Manifest ohne Docker-Ausführung auszugeben, OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>, um die Statusausgabe anzupassen, oder OPENCLAW_DOCKER_ALL_TIMINGS=0, um die Wiederverwendung von Zeitdaten zu deaktivieren. Verwenden Sie OPENCLAW_DOCKER_ALL_LIVE_MODE=skip nur für deterministische/lokale Lanes oder OPENCLAW_DOCKER_ALL_LIVE_MODE=only nur für Live-Provider-Lanes; Package-Aliasse sind pnpm test:docker:local:all und pnpm test:docker:live:all. Der Nur-Live-Modus führt Main- und Tail-Live-Lanes in einem längste-zuerst-Pool zusammen, sodass Provider-Buckets Claude-, Codex- und Gemini-Arbeiten gemeinsam packen können. Der Runner plant nach dem ersten Fehler keine neuen gepoolten Lanes mehr ein, außer OPENCLAW_DOCKER_ALL_FAIL_FAST=0 ist gesetzt, und jede Lane hat ein Fallback-Timeout von 120 Minuten, das mit OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS überschrieben werden kann; ausgewählte Live-/Tail-Lanes verwenden strengere Caps pro Lane. CLI-Backend-Docker-Setup-Befehle haben ein eigenes Timeout über OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS (Standard 180). Pro-Lane-Logs, summary.json, failures.json und Phasenzeiten werden unter .artifacts/docker-tests/<run-id>/ geschrieben; verwenden Sie pnpm test:docker:timings <summary.json>, um langsame Lanes zu untersuchen, und pnpm test:docker:rerun <run-id|summary.json|failures.json>, um günstige gezielte Wiederholungsbefehle auszugeben.

• pnpm test:docker:browser-cdp-snapshot: Erstellt einen Chromium-gestützten Source-E2E-Container, startet rohes CDP plus einen isolierten Gateway, führt browser doctor --deep aus und verifiziert, dass CDP-Rollen-Snapshots Link-URLs, zu Klickzielen hochgestufte Cursor-Elemente, iframe-Referenzen und Frame-Metadaten enthalten.

• pnpm test:docker:skill-install: Installiert den gepackten OpenClaw-Tarball in einem minimalen Docker-Runner, deaktiviert skills.install.allowUploadedArchives, löst einen aktuellen Skill-Slug aus der Live-ClawHub-Suche auf, installiert ihn über openclaw skills install und verifiziert SKILL.md, .clawhub/origin.json, .clawhub/lock.json und skills info --json.

• CLI-Backend-Live-Docker-Probes können als fokussierte Lanes ausgeführt werden, zum Beispiel pnpm test:docker:live-cli-backend:claude, pnpm test:docker:live-cli-backend:claude:resume oder pnpm test:docker:live-cli-backend:claude:mcp. Gemini hat entsprechende :resume- und :mcp-Aliasse.

• pnpm test:docker:openwebui: Startet Dockerisierte OpenClaw + Open WebUI, meldet sich über Open WebUI an, prüft /api/models und führt dann einen echten proxied Chat über /api/chat/completions aus. Erfordert einen nutzbaren Live-Model-Key, lädt ein externes Open WebUI-Image und ist nicht erwartungsgemäß so CI-stabil wie die normalen Unit-/E2E-Suites.

• pnpm test:docker:mcp-channels: Startet einen vorbefüllten Gateway-Container und einen zweiten Client-Container, der openclaw mcp serve startet, und verifiziert dann geroutete Conversation Discovery, Transcript-Lesezugriffe, Attachment-Metadaten, Live-Event-Queue-Verhalten, Outbound-Send-Routing sowie Claude-artige Channel- und Berechtigungsbenachrichtigungen über die echte stdio-Bridge. Die Claude-Benachrichtigungsassertion liest die rohen stdio-MCP-Frames direkt, sodass der Smoke widerspiegelt, was die Bridge tatsächlich ausgibt.

• pnpm test:docker:upgrade-survivor: Installiert den gepackten OpenClaw-Tarball über ein verschmutztes Altbenutzer-Fixture, führt Package-Update plus nicht interaktiven Doctor ohne Live-Provider- oder Channel-Keys aus, startet dann einen Loopback-Gateway und prüft, dass Agenten, Channel-Konfiguration, Plugin-Allowlisten, Workspace-/Session-Dateien, veralteter Legacy-Plugin-Abhängigkeitszustand, Start und RPC-Status erhalten bleiben.

• pnpm test:docker:published-upgrade-survivor: Installiert standardmäßig openclaw@latest, seeding realistische Bestandsbenutzerdateien ohne Live-Provider- oder Channel-Keys, konfiguriert diese Baseline mit einem eingebetteten openclaw config set-Befehlsrezept, aktualisiert diese veröffentlichte Installation auf den gepackten OpenClaw-Tarball, führt den nicht interaktiven Doctor aus, schreibt .artifacts/upgrade-survivor/summary.json, startet dann einen Loopback-Gateway und prüft, dass konfigurierte Intents, Workspace-/Session-Dateien, veraltete Plugin-Konfiguration und Legacy-Abhängigkeitszustand, Start, /healthz, /readyz und RPC-Status erhalten bleiben oder sauber repariert werden. Überschreiben Sie eine Baseline mit OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC, erweitern Sie eine exakte lokale Matrix mit OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS wie openclaw@2026.5.2 openclaw@2026.4.23 openclaw@2026.4.15 oder fügen Sie Szenario-Fixtures mit OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues hinzu; das reported-issues-Set enthält configured-plugin-installs, um zu verifizieren, dass konfigurierte externe OpenClaw-Plugins während des Upgrades automatisch installiert werden, und stale-source-plugin-shadow, um zu verhindern, dass source-only Plugin-Schatten den Start beschädigen. Package Acceptance stellt diese als published_upgrade_survivor_baseline, published_upgrade_survivor_baselines und published_upgrade_survivor_scenarios bereit und löst Meta-Baseline-Tokens wie last-stable-4 oder all-since-2026.4.23 auf, bevor exakte Package-Spezifikationen an Docker-Lanes übergeben werden.

• pnpm test:docker:update-migration: Führt das Published-Upgrade-Survivor-Harness im bereinigungsintensiven plugin-deps-cleanup-Szenario aus und startet standardmäßig bei openclaw@2026.4.23. Der separate Update Migration-Workflow erweitert diese Lane mit baselines=all-since-2026.4.23, sodass jedes stabile veröffentlichte Package ab .23 auf den Kandidaten aktualisiert wird und die Bereinigung konfigurierter Plugin-Abhängigkeiten außerhalb der Full-Release-CI nachweist.

• pnpm test:docker:plugins: Führt Install-/Update-Smokes für lokale Pfade, file:, npm-Registry-Packages mit gehoisteten Abhängigkeiten, bewegliche Git-Refs, ClawHub-Fixtures, Marketplace-Updates und Claude-Bundle-Aktivierung/-Inspektion aus.

Lokales PR-Gate

Führen Sie für lokale PR-Lande-/Gate-Prüfungen Folgendes aus:

• pnpm check:changed
• pnpm check
• pnpm check:test-types
• pnpm build
• pnpm test
• pnpm check:docs

Wenn pnpm test auf einem ausgelasteten Host flakig ist, führen Sie es einmal erneut aus, bevor Sie es als Regression behandeln, und isolieren Sie dann mit pnpm test <path/to/test>. Verwenden Sie für hosts mit begrenztem Arbeitsspeicher:

• OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test
• OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed

Modelllatenz-Benchmark (lokale Schlüssel)

Skript: scripts/bench-model.ts

Verwendung:

• pnpm tsx scripts/bench-model.ts --runs 10
• Optionale Umgebung: MINIMAX_API_KEY, MINIMAX_BASE_URL, MINIMAX_MODEL, ANTHROPIC_API_KEY
• Standard-Prompt: "Antworte mit einem einzigen Wort: ok. Keine Satzzeichen oder zusätzlicher Text."

Letzter Lauf (2025-12-31, 20 Läufe):

• minimax Median 1279ms (min. 1114, max. 2431)
• opus Median 2454ms (min. 1224, max. 3170)

CLI-Start-Benchmark

Skript: scripts/bench-cli-startup.ts

Verwendung:

• pnpm test:startup:bench
• pnpm test:startup:bench:smoke
• pnpm test:startup:bench:save
• pnpm test:startup:bench:update
• pnpm test:startup:bench:check
• pnpm tsx scripts/bench-cli-startup.ts
• pnpm tsx scripts/bench-cli-startup.ts --runs 12
• pnpm tsx scripts/bench-cli-startup.ts --preset real
• pnpm tsx scripts/bench-cli-startup.ts --preset real --case status --case gatewayStatus --runs 3
• pnpm tsx scripts/bench-cli-startup.ts --preset real --case tasksJson --case tasksListJson --case tasksAuditJson --runs 3
• pnpm tsx scripts/bench-cli-startup.ts --entry openclaw.mjs --entry-secondary dist/entry.js --preset all
• pnpm tsx scripts/bench-cli-startup.ts --preset all --output .artifacts/cli-startup-bench-all.json
• pnpm tsx scripts/bench-cli-startup.ts --preset real --case gatewayStatusJson --output .artifacts/cli-startup-bench-smoke.json
• pnpm tsx scripts/bench-cli-startup.ts --preset real --cpu-prof-dir .artifacts/cli-cpu
• pnpm tsx scripts/bench-cli-startup.ts --json

Voreinstellungen:

• startup: --version, --help, health, health --json, status --json, status
• real: health, status, status --json, sessions, sessions --json, tasks --json, tasks list --json, tasks audit --json, agents list --json, gateway status, gateway status --json, gateway health --json, config get gateway.port
• all: beide Voreinstellungen

Die Ausgabe enthält sampleCount, Durchschnitt, p50, p95, min./max., Exit-Code-/Signalverteilung und maximale RSS-Zusammenfassungen für jeden Befehl. Optional schreibt --cpu-prof-dir / --heap-prof-dir V8-Profile pro Lauf, sodass Zeitmessung und Profilerfassung denselben Harness verwenden.

Konventionen für gespeicherte Ausgaben:

• pnpm test:startup:bench:smoke schreibt das gezielte Smoke-Artefakt nach .artifacts/cli-startup-bench-smoke.json
• pnpm test:startup:bench:save schreibt das Artefakt der vollständigen Suite nach .artifacts/cli-startup-bench-all.json mit runs=5 und warmup=1
• pnpm test:startup:bench:update aktualisiert das eingecheckte Baseline-Fixture unter test/fixtures/cli-startup-bench.json mit runs=5 und warmup=1

Eingechecktes Fixture:

• test/fixtures/cli-startup-bench.json
• Aktualisieren mit pnpm test:startup:bench:update
• Aktuelle Ergebnisse mit dem Fixture vergleichen mit pnpm test:startup:bench:check

Gateway-Start-Benchmark

Skript: scripts/bench-gateway-startup.ts

Der Benchmark verwendet standardmäßig den gebauten CLI-Einstieg unter dist/entry.js; führen Sie pnpm build aus, bevor Sie die Package-Script-Befehle verwenden. Um stattdessen den Quell-Runner zu messen, übergeben Sie --entry scripts/run-node.mjs und halten Sie diese Ergebnisse getrennt von Baselines mit gebautem Einstieg.

Verwendung:

• pnpm test:startup:gateway -- --runs 5 --warmup 1
• pnpm test:startup:gateway -- --case default --runs 10 --warmup 1
• pnpm test:startup:gateway -- --case skipChannels --case fiftyPlugins --runs 5
• node --import tsx scripts/bench-gateway-startup.ts --case default --runs 5 --output .artifacts/gateway-startup.json
• node --import tsx scripts/bench-gateway-startup.ts --case default --runs 3 --cpu-prof-dir .artifacts/gateway-startup-cpu

Fall-IDs:

• default: normaler Gateway-Start.
• skipChannels: Gateway-Start mit übersprungenem Kanalstart.
• oneInternalHook: ein konfigurierter interner Hook.
• allInternalHooks: alle internen Hooks.
• fiftyPlugins: 50 Manifest-Plugins.
• fiftyStartupLazyPlugins: 50 startup-lazy Manifest-Plugins.

Die Ausgabe enthält die erste Prozessausgabe, /healthz, /readyz, die HTTP-Listen-Logzeit, die Gateway-Ready-Logzeit, CPU-Zeit, CPU-Core-Verhältnis, max. RSS, Heap, Startup-Trace- Metriken, Event-Loop-Verzögerung und Detailmetriken der Plugin-Lookup-Tabelle. Das Skript aktiviert OPENCLAW_GATEWAY_STARTUP_TRACE=1 in der Kind-Gateway-Umgebung.

Lesen Sie /healthz als Liveness: Der HTTP-Server kann antworten. Lesen Sie /readyz als nutzbare Bereitschaft: Startup-Plugin-Sidecars, Kanäle und ready-kritische Post-Attach-Arbeit sind abgeschlossen. Gateway-Startup-Hooks werden asynchron ausgelöst und sind nicht Teil der Bereitschaftsgarantie. Die Ready-Logzeit ist der interne Ready-Log-Zeitstempel des Gateway; sie ist für prozessseitige Zuordnung nützlich, ersetzt aber nicht den externen /readyz-Probe.

Verwenden Sie JSON-Ausgabe oder --output, wenn Sie Änderungen vergleichen. Verwenden Sie --cpu-prof-dir erst, nachdem die Trace-Ausgabe auf Import-, Compile- oder CPU-gebundene Arbeit hinweist, die nicht allein aus Phasenzeiten erklärt werden kann. Vergleichen Sie Quell-Runner-Ergebnisse nicht mit gebauten dist/entry.js-Ergebnissen als derselben Baseline.

Gateway-Neustart-Benchmark

Skript: scripts/bench-gateway-restart.ts

Der Neustart-Benchmark wird nur auf macOS und Linux unterstützt. Er verwendet SIGUSR1 für In-Process-Neustarts und schlägt unter Windows sofort fehl.

Der Benchmark verwendet standardmäßig den gebauten CLI-Einstieg unter dist/entry.js; führen Sie pnpm build aus, bevor Sie die Package-Script-Befehle verwenden. Um stattdessen den Quell-Runner zu messen, übergeben Sie --entry scripts/run-node.mjs und halten Sie diese Ergebnisse getrennt von Baselines mit gebautem Einstieg.

Verwendung:

• pnpm test:restart:gateway -- --case skipChannels --runs 1 --restarts 5
• pnpm test:restart:gateway -- --case default --runs 3 --restarts 3 --warmup 1
• pnpm test:restart:gateway -- --case skipChannelsAcpxProbe --case skipChannelsNoAcpxProbe --runs 1 --restarts 5
• node --import tsx scripts/bench-gateway-restart.ts --case fiftyPlugins --runs 1 --restarts 5 --output .artifacts/gateway-restart.json
• node --import tsx scripts/bench-gateway-restart.ts --json

Fall-IDs:

• skipChannels: Neustart mit übersprungenen Kanälen.
• skipChannelsAcpxProbe: Neustart mit übersprungenen Kanälen und eingeschaltetem ACPX-Startup-Probe.
• skipChannelsNoAcpxProbe: Neustart mit übersprungenen Kanälen und ausgeschaltetem ACPX-Startup-Probe.
• default: normaler Neustart.
• fiftyPlugins: Neustart mit 50 Manifest-Plugins.

Die Ausgabe enthält das nächste /healthz, das nächste /readyz, Ausfallzeit, Restart-Ready-Timing, CPU, RSS, Startup-Trace-Metriken für den Ersatzprozess und Restart-Trace- Metriken für Signalverarbeitung, Active-Work-Drain, Close-Phasen, nächsten Start, Ready- Timing und Speicher-Snapshots. Das Skript aktiviert OPENCLAW_GATEWAY_STARTUP_TRACE=1 und OPENCLAW_GATEWAY_RESTART_TRACE=1 in der Kind-Gateway-Umgebung.

Verwenden Sie diesen Benchmark, wenn eine Änderung Neustart-Signalisierung, Close-Handler, Startup-after-Restart, Sidecar-Shutdown, Service-Übergabe oder Bereitschaft nach Neustart betrifft. Beginnen Sie mit skipChannels, wenn Sie Gateway-Mechanik vom Kanal- Start isolieren. Verwenden Sie default oder Plugin-lastige Fälle erst, nachdem der enge Fall den Neustartpfad erklärt.

Trace-Metriken sind Zuordnungshinweise, keine Urteile. Eine Neustartänderung sollte anhand mehrerer Samples, der passenden Owner-Spanne, des /healthz- und /readyz- Verhaltens und des benutzersichtbaren Neustartvertrags beurteilt werden.

Onboarding-E2E (Docker)

Docker ist optional; dies wird nur für containerisierte Onboarding-Smoke-Tests benötigt.

Vollständiger Cold-Start-Ablauf in einem sauberen Linux-Container:

scripts/e2e/onboard-docker.sh

Dieses Skript steuert den interaktiven Assistenten über ein Pseudo-TTY, verifiziert Konfigurations-/Workspace-/Session-Dateien, startet dann das Gateway und führt openclaw health aus.

QR-Import-Smoke (Docker)

Stellt sicher, dass der gepflegte QR-Laufzeithelfer unter den unterstützten Docker-Node-Laufzeiten geladen wird (Node 24 Standard, Node 22 kompatibel):

pnpm test:docker:qr

Verwandt

• Tests
• Live testen
• Updates und Plugins testen