Die Test-Lanes ausführen

SupaCloud führt seine Tests in benannten Lanes aus. Jede Lane hat eine Aufgabe, einen ehrlichen Coverage-Nenner und einen Ort in der CI. Diese Seite sagt dir, welche Lane zu deiner Änderung gehört und wie du sie lokal ausführst.

Tipp

Die vollständige Befehls- und CI-Job-Matrix steht in docs/testing.md im Repository. Diese Seite ist die aufgabenorientierte Kurzform.

Die passende Lane

Du hast geändert…	Führe das aus
Rust-Logik oder Persistenz	cargo nextest run --workspace --features test-support
Eine Svelte-Komponente	npm run test:component (in web/)
Frontend-TypeScript (Stores, Contracts, CLI)	npx vitest run (in web/)
Einen nutzersichtbaren Ablauf end-to-end	npm run test:e2e:nightly gegen einen gebooteten Stack
Eine Script-Runtime, einen Connector oder eine andere Host-Grenze	die system-external-Lane (unten)
Die Marketing-Site	npm run build && node scripts/smoke.mjs (in marketing/)
Den Agent-Runner	npm test (in agent-runners/unified/)

Backend-Lanes

Die nextest-Profile teilen die Rust-Suite danach auf, was ein Test braucht:

cd server
cargo nextest run --workspace --features test-support -P hermetic-unit   # ohne DB
cargo nextest run --workspace --features test-support -P db-integration  # braucht Postgres
cargo nextest run --workspace --features test-support -P contract        # Drift-Gates

Postgres für die DB-Lane kommt aus der Compose-Datei des Repos:

docker compose -f compose.test.yml up -d postgres
export TEST_DATABASE_URL="postgresql://supacloud:supacloud@127.0.0.1:55433/supacloud_test"

Die system-external-Lane

Manche Tests fahren eine echte Runtime: die WebAssembly-Script-Interpreter, den Connector-Egress-Pfad, die FinTS-Komponente. Sie brauchen diese Runtimes auf der Platte. Einmal bereitstellen, dann die Lane ausführen:

bash scripts/build-script-runtimes.sh          # baut js/ts (+ py, wenn componentize-py vorhanden ist)
cd server
REQUIRE_SYSTEM_E2E=1 \
SUPACLOUD_SCRIPT_RUNTIME_DIR="$PWD/assets/script-runtimes" \
  cargo nextest run --workspace --features test-support -P system-external --run-ignored all

Achtung

REQUIRE_SYSTEM_E2E=1 macht diese Lane vertrauenswürdig. Mit dem Flag lässt eine fehlende Runtime den Test scheitern. Ohne das Flag druckt der Test einen maschinenlesbaren SUPACLOUD-TEST-SKIP-Marker und kehrt früh zurück — sichtbar in der CI-Step-Summary, niemals ein stiller Pass. Die CI führt diese Lane nächtlich mit gesetztem Flag aus.

Komponententests

Komponententests mounten die echte Svelte-Komponente und fahren ihre Zustände (laden / leer / Fehler / Berechtigung / Ergebnis) sowie ihre Handler. Sie liegen neben der Komponente als Foo.component.test.ts:

cd web
npm run test:component                 # die ganze Component-Lane
npm run coverage:component             # + der ehrliche All-Files-Report und sein Ratchet

Der Coverage-Nenner umfasst jede .svelte- und .svelte.ts-Datei — eine Komponente, die niemand testet, erscheint als 0 %, nie als abwesend. Das Ratchet scheitert nur bei einem Absinken unter die committete Baseline: Eine neue Komponente rötet das Gate also nie, verrottende Coverage schon.

Browser-Tests

Zwei Browser-Suiten, zwei Zwecke:

• Mock-Suite (npm run test:smoke) — vollständig eigenständig: Fixture-Daten, geskriptetes WebSocket, eigener Preview-Server. Schnell, ohne Backend.
• Echte Suite (npm run test:e2e:nightly) — ein gebooteter Stack (Server, Datenbank, geseedete Daten). Sie deckt die Erfolgspfade und die Fehlerpfade ab: falsches Passwort, abgelaufene Sitzung, fehlende Berechtigung, Validierungskonflikt, Serverfehler, Doppelklick, verworfene Änderung.

Den echten Stack bootest du mit bash scripts/e2e/boot-nightly-stack.sh, und mit bash scripts/e2e/cleanup-nightly-stack.sh räumst du ihn wieder ab.