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"

DB-gebundene Zellen in einem Agent-Container (Wand 6 Option C): Ein Agent, der DB-gebundene Zellen fährt, darf nicht von Host-Infrastruktur abhängen. SUPACLOUD_AGENT_TEST_DB=true ist die Fähigkeits-Schranke der Instanz: sie erlaubt den Sidecar, aktiviert ihn aber nicht. Zusätzlich muss die Aufgabe ihn wählen (tasks.config.test_db = true); eine nicht gewählte Aufgabe bekommt keinen Sidecar. Ist die Wahl getroffen, startet der Server je Aufgabe einen flüchtigen postgres-Sidecar (sc-testdb-<task_id>) im selben Docker-Netz wie der Agent und injiziert TEST_DATABASE_URL. Das Image ist über AGENT_TEST_DB_IMAGE wählbar (Standard postgres:18). Ein explizit gesetztes TEST_DATABASE_URL des Aufrufers (z. B. aus einem Projekt- oder Capability- Secret) hat Vorrang: der Sidecar wird unterdrückt und der Wert niemals überschrieben — ein Workspace, der gegen seine eigene Datenbank testet, wird nicht still auf einen leeren Sidecar umgeleitet. Das Passwort (und die volle URL) landet im Redaktionssatz des Laufs, damit ein Agent, der seine Env ausgibt, die Zugangsdaten nicht in events persistiert. Die Funktion ist standardmäßig aus; der Sidecar wird mit dem Agent-Container wieder entfernt, und kann er nicht starten, wird der Agent-Container gar nicht erst erstellt.

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.

Welche Spec welche Abkürzung nimmt — gemockte API, geseedetes Ergebnis, Datenbank-Stempel — und wie weit der E2E-Standard des Handbuchs erfüllt ist, steht in der E2E-Spec-Wahrheitstabelle.