---
read_when:
    - Uruchamianie lub naprawianie testów
summary: Jak uruchamiać testy lokalnie (vitest) i kiedy używać trybów wymuszania/pokrycia
title: Testy
x-i18n:
    generated_at: "2026-06-28T00:13:18Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 7d1aed76ed59713ee320eb2d18dc8c392ea7a810096a0ef3131388001bbe5d8d
    source_path: reference/test.md
    workflow: 16
---

- Pełny zestaw testowy (zestawy, live, Docker): [Testowanie](/pl/help/testing)
- Walidacja aktualizacji i pakietów Plugin: [Testowanie aktualizacji i pluginów](/pl/help/testing-updates-plugins)

- 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`](https://github.com/openclaw/openclaw/blob/main/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`](https://github.com/openclaw/openclaw/blob/main/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`](https://github.com/openclaw/openclaw/blob/main/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`](https://github.com/openclaw/openclaw/blob/main/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:

```bash
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):

```bash
pnpm test:docker:qr
```

## Powiązane

- [Testowanie](/pl/help/testing)
- [Testowanie live](/pl/help/testing-live)
- [Testowanie aktualizacji i pluginów](/pl/help/testing-updates-plugins)