Testy

• Pełny zestaw testowy (zestawy, live, Docker): Testowanie

• Walidacja aktualizacji i pakietów Plugin: Testowanie aktualizacji i pluginów

• Rutynowa kolejność testów lokalnych:

  1. pnpm test:changed jako dowód Vitest dla zakresu zmian.
  2. pnpm test <path-or-filter> dla jednego pliku, katalogu albo jawnego celu.
  3. pnpm test tylko wtedy, gdy celowo potrzebujesz pełnego lokalnego zestawu Vitest.

• pnpm test:force: zabija każdy pozostały proces gateway zajmujący domyślny port sterowania, a następnie uruchamia pełny zestaw Vitest z izolowanym portem gateway, aby testy serwera nie kolidowały z działającą instancją. Użyj tego, gdy wcześniejsze uruchomienie gateway pozostawiło port 18789 zajęty.

• pnpm test:coverage: uruchamia zestaw testów jednostkowych z pokryciem V8 (przez vitest.unit.config.ts). To bramka pokrycia domyślnej ścieżki jednostkowej, a nie pokrycie wszystkich plików w całym repozytorium. Progi to 70% dla wierszy/funkcji/instrukcji i 55% dla gałęzi. Ponieważ coverage.all ma wartość false, a domyślna ścieżka ogranicza uwzględnianie pokrycia do niewymagających szybkiej ścieżki testów jednostkowych z sąsiednimi plikami źródłowymi, bramka mierzy źródła należące do tej ścieżki zamiast każdego przechodniego importu, który przypadkowo załaduje.

• pnpm test:coverage:changed: uruchamia pokrycie jednostkowe tylko dla plików zmienionych od origin/main.

• pnpm test:changed: tani, inteligentny przebieg testów dla zmian. Uruchamia precyzyjne cele z bezpośrednich edycji testów, sąsiednich plików *.test.ts, jawnych mapowań źródeł i lokalnego grafu importów. Szerokie zmiany konfiguracji/pakietów są pomijane, chyba że mapują się na precyzyjne testy.

• OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed: jawny szeroki przebieg testów dla zmian. Użyj go, gdy edycja harnessu testowego/konfiguracji/pakietu powinna przejść awaryjnie na szersze zachowanie Vitest dla testów zmienionych.

• pnpm changed:lanes: pokazuje ścieżki architektoniczne wyzwolone przez diff względem origin/main.

• pnpm check:changed: poza CI domyślnie deleguje do Crabbox/Testbox, a następnie uruchamia inteligentną bramkę sprawdzania zmian dla diffu względem origin/main wewnątrz zdalnego procesu potomnego. Uruchamia typecheck, lint i polecenia strażników dla dotkniętych ścieżek architektonicznych, ale nie uruchamia testów Vitest. Użyj pnpm test:changed albo jawnego pnpm test <target> jako dowodu testowego.

• Drzewa robocze Codex i połączone/rzadkie checkouty: unikaj bezpośredniego lokalnego pnpm test*, pnpm check* i pnpm crabbox:run, chyba że zweryfikowano, że pnpm nie będzie uzgadniać zależności. Dla niewielkiego dowodu z jawnego pliku użyj node scripts/run-vitest.mjs <path-or-filter>; dla bramek zmian albo szerokiego dowodu użyj 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, aby pnpm działał wewnątrz Testbox.

• Dowód Testbox przez Crabbox: użyj końcowego exitCode wrappera i JSON z czasem jako wyniku polecenia. Delegowany przebieg Blacksmith GitHub Actions może pokazać cancelled po udanym poleceniu SSH, ponieważ Testbox jest zatrzymywany z zewnątrz akcji keepalive; przed potraktowaniem tego jako niepowodzenia testu zweryfikuj podsumowanie wrappera i wyjście polecenia.

• OPENCLAW_HEAVY_CHECK_LOCK_SCOPE=worktree <local-heavy-check command>: utrzymuje serializację ciężkich sprawdzeń w bieżącym drzewie roboczym zamiast w wspólnym katalogu Git dla poleceń takich jak pnpm check:changed i celowane pnpm test .... Używaj tego tylko na lokalnych hostach o dużej pojemności, gdy celowo uruchamiasz niezależne sprawdzenia w połączonych drzewach roboczych.

• pnpm test: kieruje jawne cele plików/katalogów przez zakresowe ścieżki Vitest. Uruchomienia bez celu są dowodem pełnego zestawu: używają stałych grup shardów, rozwijają się do konfiguracji liści dla lokalnego wykonania równoległego i wypisują oczekiwany lokalny fanout shardów przed startem. Grupa rozszerzeń zawsze rozwija się do konfiguracji shardów per rozszerzenie zamiast jednego ogromnego procesu projektu głównego.

• Przebiegi wrappera testowego kończą się krótkim podsumowaniem [test] passed|failed|skipped ... in .... Własny wiersz czasu trwania Vitest pozostaje szczegółem per shard.

• Wspólny stan testowy OpenClaw: używaj src/test-utils/openclaw-test-state.ts z Vitest, gdy test potrzebuje izolowanego HOME, OPENCLAW_STATE_DIR, OPENCLAW_CONFIG_PATH, fixture konfiguracji, workspace, katalogu agenta albo magazynu profili auth.

• pnpm test:env-mutations:report: nieblokujący raport testów i harnessów, które bezpośrednio mutują HOME, OPENCLAW_STATE_DIR, OPENCLAW_CONFIG_PATH, OPENCLAW_WORKSPACE_DIR albo powiązane klucze env OpenClaw. Użyj go, aby znaleźć kandydatów do migracji na wspólny helper stanu testowego.

• Mockowane E2E Control UI: użyj pnpm test:ui:e2e dla ścieżki Vitest + Playwright, która uruchamia Vite Control UI i steruje prawdziwą stroną Chromium względem mockowanego WebSocket Gateway. Testy znajdują się w ui/src/**/*.e2e.test.ts; wspólne mocki i kontrolki znajdują się w ui/src/test-helpers/control-ui-e2e.ts. pnpm test:e2e obejmuje tę ścieżkę. W drzewach roboczych Codex preferuj 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 dla małego celowanego dowodu po zainstalowaniu zależności albo Testbox/Crabbox dla szerszego dowodu GUI.

• Helpery E2E procesu: użyj test/helpers/openclaw-test-instance.ts, gdy test E2E na poziomie procesu Vitest potrzebuje działającego Gateway, env CLI, przechwytywania logów i sprzątania w jednym miejscu.

• Testy TUI PTY: użyj node scripts/run-vitest.mjs run --config test/vitest/vitest.tui-pty.config.ts dla szybkiej ścieżki PTY z fałszywym backendem. Użyj OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 albo pnpm tui:pty:test:watch --mode local dla wolniejszego smoke tui --local, który mockuje tylko zewnętrzny endpoint modelu. Asercje opieraj na stabilnym widocznym tekście albo wywołaniach fixture, nie na surowych migawkach ANSI.

• Helpery Docker/Bash E2E: ścieżki, które źródłują scripts/lib/docker-e2e-image.sh, mogą przekazać docker_e2e_test_state_shell_b64 <label> <scenario> do kontenera i zdekodować go przez scripts/lib/openclaw-e2e-instance.sh; skrypty z wieloma home mogą przekazać docker_e2e_test_state_function_b64 i wywołać openclaw_test_state_create <label> <scenario> w każdym przepływie. Wywołujący niższego poziomu mogą użyć scripts/lib/openclaw-test-state.mjs shell --label <name> --scenario <name> dla fragmentu powłoki w kontenerze albo node scripts/lib/openclaw-test-state.mjs -- create --label <name> --scenario <name> --env-file <path> --json dla możliwego do źródłowania pliku env hosta. -- przed create zapobiega traktowaniu --env-file jako flagi Node przez nowsze runtime Node. Ścieżki Docker/Bash, które uruchamiają Gateway, mogą źródłować scripts/lib/openclaw-e2e-instance.sh wewnątrz kontenera dla rozwiązywania entrypointu, mockowanego startu OpenAI, uruchomienia Gateway na pierwszym planie/w tle, sond gotowości, eksportu env stanu, zrzutów logów i sprzątania procesów.

• Pełne przebiegi shardów, przebiegi rozszerzeń i przebiegi ze wzorcem include aktualizują lokalne dane czasu w .artifacts/vitest-shard-timings.json; późniejsze przebiegi całej konfiguracji używają tych czasów do równoważenia wolnych i szybkich shardów. Shardy CI ze wzorcem include dopisują nazwę sharda do klucza czasu, co utrzymuje widoczność przefiltrowanych czasów shardów bez zastępowania danych czasu całej konfiguracji. Ustaw OPENCLAW_TEST_PROJECTS_TIMINGS=0, aby zignorować lokalny artefakt czasu.

• Wybrane pliki testowe plugin-sdk i commands przechodzą teraz przez dedykowane lekkie ścieżki, które zachowują tylko test/setup.ts, pozostawiając ciężkie przypadki runtime na ich istniejących ścieżkach.

• Pliki źródłowe z sąsiednimi testami mapują się na ten sąsiedni test przed przejściem awaryjnym na szersze globs katalogów. Edycje helperów pod src/channels/plugins/contracts/test-helpers, src/plugin-sdk/test-helpers i src/plugins/contracts używają lokalnego grafu importów, aby uruchamiać importujące testy zamiast szerokiego uruchamiania każdego sharda, gdy ścieżka zależności jest precyzyjna.

• auto-reply dzieli się teraz także na trzy dedykowane konfiguracje (core, top-level, reply), aby harness odpowiedzi nie dominował lżejszych testów najwyższego poziomu statusu/tokenów/helperów.

• Bazowa konfiguracja Vitest domyślnie używa teraz pool: "threads" i isolate: false, ze współdzielonym nieizolowanym runnerem włączonym w konfiguracjach całego repozytorium.

• pnpm test:channels uruchamia vitest.channels.config.ts.

• pnpm test:extensions i pnpm test extensions uruchamiają wszystkie shardy rozszerzeń/Pluginów. Ciężkie Pluginy kanałów, Plugin przeglądarki i OpenAI działają jako dedykowane shardy; inne grupy Pluginów pozostają zbatchowane. Użyj pnpm test extensions/<id> dla jednej ścieżki bundled Plugin.

• pnpm test:perf:imports: włącza raportowanie czasu trwania importów Vitest i rozbicia importów, nadal używając zakresowego routingu ścieżek dla jawnych celów plików/katalogów.

• pnpm test:perf:imports:changed: to samo profilowanie importów, ale tylko dla plików zmienionych od origin/main.

• pnpm test:perf:changed:bench -- --ref <git-ref> benchmarkuje routowaną ścieżkę trybu zmian względem natywnego przebiegu projektu głównego dla tego samego zatwierdzonego diffu git.

• pnpm test:perf:changed:bench -- --worktree benchmarkuje bieżący zestaw zmian drzewa roboczego bez wcześniejszego commitowania.

• pnpm test:perf:profile:main: zapisuje profil CPU dla głównego wątku Vitest (.artifacts/vitest-main-profile).

• pnpm test:perf:profile:runner: zapisuje profile CPU + heap dla runnera jednostkowego (.artifacts/vitest-runner-profile).

• pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json: uruchamia szeregowo każdą konfigurację liścia Vitest pełnego zestawu i zapisuje zgrupowane dane czasu trwania oraz artefakty JSON/log per konfiguracja. Test Performance Agent używa tego jako punktu bazowego przed próbą napraw wolnych testów.

• pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json: porównuje zgrupowane raporty po zmianie ukierunkowanej na wydajność.

• pnpm test:docker:timings <summary.json> sprawdza wolne ścieżki Docker po przebiegu Docker all; użyj pnpm test:docker:rerun <run-id|summary.json|failures.json>, aby wypisać tanie, celowane polecenia ponownego uruchomienia z tych samych artefaktów.

• Integracja Gateway: włączana jawnie przez OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test albo pnpm test:gateway.

• pnpm test:e2e: uruchamia agregat E2E repozytorium: smoke testy gateway end-to-end oraz mockowaną przeglądarkową ścieżkę E2E Control UI.

• pnpm test:e2e:gateway: uruchamia smoke testy gateway end-to-end (parowanie wielu instancji WS/HTTP/node). Domyślnie używa threads + isolate: false z adaptacyjnymi workerami w vitest.e2e.config.ts; dostrój przez OPENCLAW_E2E_WORKERS=<n> i ustaw OPENCLAW_E2E_VERBOSE=1 dla szczegółowych logów.

• pnpm test:live: uruchamia testy live providerów (minimax/zai). Wymaga kluczy API i LIVE=1 (albo właściwego dla providera *_LIVE_TEST=1), aby przestać pomijać.

• pnpm test:docker:all: Buduje współdzielony obraz testów live, pakuje OpenClaw jednorazowo jako tarball npm, buduje/ponownie wykorzystuje podstawowy obraz runnera Node/Git oraz obraz funkcjonalny, który instaluje ten tarball w /app, a następnie uruchamia pasma smoke Dockera z OPENCLAW_SKIP_DOCKER_BUILD=1 przez ważony harmonogram. Obraz podstawowy (OPENCLAW_DOCKER_E2E_BARE_IMAGE) jest używany dla pasm instalatora/aktualizacji/zależności Plugin; te pasma montują wcześniej zbudowany tarball zamiast używać skopiowanych źródeł repozytorium. Obraz funkcjonalny (OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE) jest używany dla zwykłych pasm funkcjonalności zbudowanej aplikacji. scripts/package-openclaw-for-docker.mjs jest jedynym lokalnym/CI pakowaczem pakietu i waliduje tarball oraz dist/postinstall-inventory.json, zanim Docker go użyje. Definicje pasm Dockera znajdują się w scripts/lib/docker-e2e-scenarios.mjs; logika planera znajduje się w scripts/lib/docker-e2e-plan.mjs; scripts/test-docker-all.mjs wykonuje wybrany plan. node scripts/test-docker-all.mjs --plan-json emituje należący do harmonogramu plan CI dla wybranych pasm, typów obrazów, potrzeb pakietu/obrazu live, scenariuszy stanu i kontroli poświadczeń bez budowania ani uruchamiania Dockera. OPENCLAW_DOCKER_ALL_PARALLELISM=<n> kontroluje sloty procesów i domyślnie wynosi 10; OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n> kontroluje pulę końcową wrażliwą na dostawcę i domyślnie wynosi 10. Limity ciężkich pasm domyślnie wynoszą OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9, OPENCLAW_DOCKER_ALL_NPM_LIMIT=5 i OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7; limity dostawców domyślnie dopuszczają jedno ciężkie pasmo na dostawcę przez OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4, OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4 i OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4. Użyj OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT lub OPENCLAW_DOCKER_ALL_DOCKER_LIMIT dla większych hostów. Jeśli jedno pasmo przekroczy efektywny limit wagi lub zasobów na hoście o niskiej równoległości, nadal może wystartować z pustej puli i będzie działać samotnie, dopóki nie zwolni pojemności. Starty pasm są domyślnie rozłożone co 2 sekundy, aby uniknąć lokalnych fal tworzenia w demonie Dockera; nadpisz to za pomocą OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>. Runner domyślnie wykonuje preflight Dockera, czyści przestarzałe kontenery E2E OpenClaw, emituje status aktywnych pasm co 30 sekund, współdzieli pamięci podręczne narzędzi CLI dostawców między zgodnymi pasmami, domyślnie ponawia przejściowe awarie dostawcy live jeden raz (OPENCLAW_DOCKER_ALL_LIVE_RETRIES=<n>) i zapisuje czasy pasm w .artifacts/docker-tests/lane-timings.json na potrzeby kolejności od najdłuższych w późniejszych uruchomieniach. Użyj OPENCLAW_DOCKER_ALL_DRY_RUN=1, aby wydrukować manifest pasm bez uruchamiania Dockera, OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>, aby dostroić wyjście statusu, albo OPENCLAW_DOCKER_ALL_TIMINGS=0, aby wyłączyć ponowne użycie pomiarów czasu. Użyj OPENCLAW_DOCKER_ALL_LIVE_MODE=skip tylko dla deterministycznych/lokalnych pasm albo OPENCLAW_DOCKER_ALL_LIVE_MODE=only tylko dla pasm dostawcy live; aliasy pakietu to pnpm test:docker:local:all i pnpm test:docker:live:all. Tryb tylko live łączy główne i końcowe pasma live w jedną pulę od najdłuższych, aby kubełki dostawców mogły wspólnie upakować prace Claude, Codex i Gemini. Runner przestaje planować nowe pasma z puli po pierwszej awarii, chyba że ustawiono OPENCLAW_DOCKER_ALL_FAIL_FAST=0, a każde pasmo ma zapasowy timeout 120 minut możliwy do nadpisania przez OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS; wybrane pasma live/końcowe używają ciaśniejszych limitów na pasmo. Polecenia konfiguracji Dockera dla backendu CLI mają własny timeout przez OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS (domyślnie 180). Logi poszczególnych pasm, summary.json, failures.json i pomiary czasu faz są zapisywane pod .artifacts/docker-tests/<run-id>/; użyj pnpm test:docker:timings <summary.json>, aby sprawdzić wolne pasma, oraz pnpm test:docker:rerun <run-id|summary.json|failures.json>, aby wydrukować tanie, ukierunkowane polecenia ponownego uruchomienia.

• pnpm test:docker:browser-cdp-snapshot: Buduje źródłowy kontener E2E oparty na Chromium, uruchamia surowe CDP oraz izolowany Gateway, uruchamia browser doctor --deep i weryfikuje, że zrzuty ról CDP zawierają adresy URL linków, klikalne elementy wypromowane przez kursor, odwołania do iframe i metadane ramek.

• pnpm test:docker:skill-install: Instaluje spakowany tarball OpenClaw w podstawowym runnerze Dockera, wyłącza skills.install.allowUploadedArchives, rozwiązuje bieżący slug Skills z wyszukiwania live ClawHub, instaluje go przez openclaw skills install i weryfikuje SKILL.md, .clawhub/origin.json, .clawhub/lock.json oraz skills info --json.

• Próby live Dockera dla backendu CLI można uruchamiać jako skupione pasma, na przykład pnpm test:docker:live-cli-backend:claude, pnpm test:docker:live-cli-backend:claude:resume lub pnpm test:docker:live-cli-backend:claude:mcp. Gemini ma odpowiadające aliasy :resume i :mcp.

• pnpm test:docker:openwebui: Uruchamia zdockeryzowane OpenClaw + Open WebUI, loguje się przez Open WebUI, sprawdza /api/models, a następnie uruchamia prawdziwy pośredniczony czat przez /api/chat/completions. Wymaga używalnego klucza modelu live, pobiera zewnętrzny obraz Open WebUI i nie oczekuje się, że będzie stabilne w CI tak jak zwykłe zestawy unit/e2e.

• pnpm test:docker:mcp-channels: Uruchamia kontener Gateway z ziarnem oraz drugi kontener klienta, który wywołuje openclaw mcp serve, a następnie weryfikuje odkrywanie routowanych konwersacji, odczyty transkryptu, metadane załączników, zachowanie kolejki zdarzeń live, routing wysyłki wychodzącej oraz powiadomienia kanału i uprawnień w stylu Claude przez prawdziwy most stdio. Asercja powiadomień Claude odczytuje bezpośrednio surowe ramki stdio MCP, aby smoke odzwierciedlał to, co most faktycznie emituje.

• pnpm test:docker:upgrade-survivor: Instaluje spakowany tarball OpenClaw na zabrudzonej fiksturze starego użytkownika, uruchamia aktualizację pakietu oraz nieinteraktywnego doctora bez kluczy dostawcy live ani kanału, a następnie uruchamia Gateway przez local loopback i sprawdza, czy agenci, konfiguracja kanału, listy dozwolone Plugin, pliki obszaru roboczego/sesji, przestarzały stan zależności legacy Plugin, uruchomienie i status RPC przetrwają.

• pnpm test:docker:published-upgrade-survivor: Domyślnie instaluje openclaw@latest, zasiewa realistyczne pliki istniejącego użytkownika bez kluczy dostawcy live ani kanału, konfiguruje tę bazę za pomocą wbudowanego przepisu polecenia openclaw config set, aktualizuje tę opublikowaną instalację do spakowanego tarballa OpenClaw, uruchamia nieinteraktywnego doctora, zapisuje .artifacts/upgrade-survivor/summary.json, a następnie uruchamia Gateway przez local loopback i sprawdza, czy skonfigurowane intencje, pliki obszaru roboczego/sesji, przestarzała konfiguracja Plugin i stan zależności legacy, uruchomienie, /healthz, /readyz oraz status RPC przetrwają albo zostaną czysto naprawione. Nadpisz jedną bazę za pomocą OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC, rozszerz dokładną lokalną macierz za pomocą OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS, na przykład openclaw@2026.5.2 openclaw@2026.4.23 openclaw@2026.4.15, albo dodaj fikstury scenariuszy za pomocą OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues; zestaw reported-issues obejmuje configured-plugin-installs, aby zweryfikować, że skonfigurowane zewnętrzne Plugin OpenClaw instalują się automatycznie podczas aktualizacji, oraz stale-source-plugin-shadow, aby cienie Plugin tylko ze źródeł nie psuły uruchomienia. Package Acceptance udostępnia je jako published_upgrade_survivor_baseline, published_upgrade_survivor_baselines i published_upgrade_survivor_scenarios oraz rozwiązuje metatokeny bazowe, takie jak last-stable-4 lub all-since-2026.4.23, zanim przekaże dokładne specyfikacje pakietów do pasm Dockera.

• pnpm test:docker:update-migration: Uruchamia harness przetrwania opublikowanej aktualizacji w scenariuszu intensywnego czyszczenia plugin-deps-cleanup, domyślnie zaczynając od openclaw@2026.4.23. Oddzielny workflow Update Migration rozszerza to pasmo za pomocą baselines=all-since-2026.4.23, aby każdy stabilny opublikowany pakiet od .23 wzwyż aktualizował się do kandydata i dowodził czyszczenia zależności skonfigurowanych Plugin poza Full Release CI.

• pnpm test:docker:plugins: Uruchamia smoke instalacji/aktualizacji dla ścieżki lokalnej, pakietów file:, pakietów rejestru npm z wyniesionymi zależnościami, ruchomych refów git, fikstur ClawHub, aktualizacji marketplace oraz włączania/inspekcji pakietu Claude.

Lokalna bramka PR

Dla lokalnych sprawdzeń scalania/bramki PR uruchom:

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

Jeśli pnpm test działa niestabilnie na obciążonym hoście, uruchom go ponownie raz, zanim uznasz to za regresję, a następnie wyizoluj problem za pomocą pnpm test <path/to/test>. Dla hostów z ograniczoną pamięcią użyj:

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

Pomiar opóźnień modeli (lokalne klucze)

Skrypt: scripts/bench-model.ts

Użycie:

• pnpm tsx scripts/bench-model.ts --runs 10
• Opcjonalne zmienne środowiskowe: MINIMAX_API_KEY, MINIMAX_BASE_URL, MINIMAX_MODEL, ANTHROPIC_API_KEY
• Domyślny prompt: "Odpowiedz jednym słowem: ok. Bez interpunkcji ani dodatkowego tekstu."

Ostatnie uruchomienie (2025-12-31, 20 uruchomień):

• mediana minimax 1279 ms (min. 1114, maks. 2431)
• mediana opus 2454 ms (min. 1224, maks. 3170)

Pomiar startu CLI

Skrypt: scripts/bench-cli-startup.ts

Użycie:

• 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

Presety:

• 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: oba presety

Dane wyjściowe obejmują sampleCount, średnią, p50, p95, min./maks., rozkład kodów wyjścia/sygnałów oraz podsumowania maksymalnego RSS dla każdego polecenia. Opcjonalne --cpu-prof-dir / --heap-prof-dir zapisuje profile V8 dla każdego uruchomienia, aby pomiar czasu i przechwytywanie profilu używały tego samego harnessa.

Konwencje zapisanych danych wyjściowych:

• pnpm test:startup:bench:smoke zapisuje docelowy artefakt smoke w .artifacts/cli-startup-bench-smoke.json
• pnpm test:startup:bench:save zapisuje artefakt pełnego zestawu w .artifacts/cli-startup-bench-all.json z użyciem runs=5 i warmup=1
• pnpm test:startup:bench:update odświeża wersjonowany fixture bazowy w test/fixtures/cli-startup-bench.json z użyciem runs=5 i warmup=1

Wersjonowany fixture:

• test/fixtures/cli-startup-bench.json
• Odśwież za pomocą pnpm test:startup:bench:update
• Porównaj bieżące wyniki z fixture za pomocą pnpm test:startup:bench:check

Pomiar startu Gateway

Skrypt: scripts/bench-gateway-startup.ts

Benchmark domyślnie używa zbudowanego punktu wejścia CLI w dist/entry.js; uruchom pnpm build przed użyciem poleceń skryptów pakietu. Aby zamiast tego zmierzyć runner źródłowy, przekaż --entry scripts/run-node.mjs i trzymaj te wyniki oddzielnie od bazowych wyników zbudowanego punktu wejścia.

Użycie:

• 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

Identyfikatory przypadków:

• default: normalny start Gateway.
• skipChannels: start Gateway z pominiętym uruchamianiem kanałów.
• oneInternalHook: jeden skonfigurowany hook wewnętrzny.
• allInternalHooks: wszystkie hooki wewnętrzne.
• fiftyPlugins: 50 pluginów manifestu.
• fiftyStartupLazyPlugins: 50 leniwie startujących pluginów manifestu.

Dane wyjściowe obejmują pierwsze dane wyjściowe procesu, /healthz, /readyz, czas logu nasłuchiwania HTTP, czas logu gotowości Gateway, czas CPU, proporcję rdzeni CPU, maksymalne RSS, stertę, metryki śladu startu, opóźnienie pętli zdarzeń oraz szczegółowe metryki tabeli wyszukiwania pluginów. Skrypt włącza OPENCLAW_GATEWAY_STARTUP_TRACE=1 w środowisku podrzędnego Gateway.

Traktuj /healthz jako żywotność: serwer HTTP może odpowiadać. Traktuj /readyz jako gotowość użytkową: sidecary pluginów startowych, kanały i krytyczne dla gotowości prace po dołączeniu zostały ustabilizowane. Hooki startowe Gateway są wysyłane asynchronicznie i nie są częścią gwarancji gotowości. Czas logu gotowości to wewnętrzny znacznik czasu logu gotowości Gateway; jest przydatny do atrybucji po stronie procesu, ale nie zastępuje zewnętrznej sondy /readyz.

Używaj danych wyjściowych JSON lub --output przy porównywaniu zmian. Używaj --cpu-prof-dir tylko po tym, jak dane śladu wskażą import, kompilację lub pracę zależną od CPU, której nie da się wyjaśnić samymi czasami faz. Nie porównuj wyników runnera źródłowego z wynikami zbudowanego dist/entry.js jako tej samej bazy.

Pomiar restartu Gateway

Skrypt: scripts/bench-gateway-restart.ts

Benchmark restartu jest obsługiwany tylko na macOS i Linuksie. Używa SIGUSR1 do restartów w procesie i natychmiast kończy się niepowodzeniem w Windows.

Benchmark domyślnie używa zbudowanego punktu wejścia CLI w dist/entry.js; uruchom pnpm build przed użyciem poleceń skryptów pakietu. Aby zamiast tego zmierzyć runner źródłowy, przekaż --entry scripts/run-node.mjs i trzymaj te wyniki oddzielnie od bazowych wyników zbudowanego punktu wejścia.

Użycie:

• 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

Identyfikatory przypadków:

• skipChannels: restart z pominiętymi kanałami.
• skipChannelsAcpxProbe: restart z pominiętymi kanałami i włączoną sondą startową ACPX.
• skipChannelsNoAcpxProbe: restart z pominiętymi kanałami i wyłączoną sondą startową ACPX.
• default: normalny restart.
• fiftyPlugins: restart z 50 pluginami manifestu.

Dane wyjściowe obejmują kolejne /healthz, kolejne /readyz, przestój, czas gotowości po restarcie, CPU, RSS, metryki śladu startu dla procesu zastępczego oraz metryki śladu restartu dla obsługi sygnału, opróżniania aktywnej pracy, faz zamykania, następnego startu, czasu gotowości i snapshotów pamięci. Skrypt włącza OPENCLAW_GATEWAY_STARTUP_TRACE=1 i OPENCLAW_GATEWAY_RESTART_TRACE=1 w środowisku podrzędnego Gateway.

Użyj tego benchmarku, gdy zmiana dotyka sygnalizacji restartu, handlerów zamykania, startu po restarcie, wyłączania sidecarów, przekazania usługi lub gotowości po restarcie. Zacznij od skipChannels, gdy izolujesz mechanikę Gateway od startu kanałów. Używaj default lub przypadków z dużą liczbą pluginów dopiero wtedy, gdy wąski przypadek wyjaśni ścieżkę restartu.

Metryki śladu są wskazówkami atrybucji, a nie werdyktami. Zmianę restartu należy oceniać na podstawie wielu próbek, pasującego zakresu właściciela, zachowania /healthz i /readyz oraz widocznego dla użytkownika kontraktu restartu.

Onboarding E2E (Docker)

Docker jest opcjonalny; jest to potrzebne tylko do konteneryzowanych testów smoke onboardingu.

Pełny przepływ zimnego startu w czystym kontenerze Linux:

scripts/e2e/onboard-docker.sh

Ten skrypt prowadzi interaktywny kreator przez pseudo-tty, weryfikuje pliki config/workspace/session, a następnie uruchamia Gateway i wykonuje openclaw health.

Smoke importu QR (Docker)

Zapewnia, że utrzymywany helper runtime QR ładuje się w obsługiwanych runtime Docker Node (domyślnie Node 24, zgodność z Node 22):

pnpm test:docker:qr

Powiązane

• Testowanie
• Testowanie live
• Testowanie aktualizacji i pluginów