Zum Hauptinhalt springen
failproofai verfügt über zwei Test-Suites: Unit-Tests (schnell, gemockt) und End-to-End-Tests (echte Subprozessaufrufe).

Tests ausführen


Unit-Tests

Unit-Tests befinden sich in __tests__/ und verwenden Vitest mit jsdom.

Einen Policy-Unit-Test schreiben


End-to-End-Tests

E2E-Tests rufen das echte failproofai-Binary als Subprozess auf, leiten eine JSON-Nutzlast an stdin weiter und prüfen die stdout-Ausgabe sowie den Exit-Code. Damit wird der vollständige Integrationspfad getestet, den Claude Code verwendet.

Einrichtung

E2E-Tests führen das Binary direkt aus dem Repository-Quellcode aus. Vor dem ersten Durchlauf muss das CJS-Bundle erstellt werden, das benutzerdefinierte Hook-Dateien verwenden, wenn sie aus 'failproofai' importieren:
Anschließend die Tests ausführen:
dist/ muss neu gebaut werden, wenn die öffentliche Hook-API geändert wird (src/hooks/custom-hooks-registry.ts, src/hooks/policy-helpers.ts oder src/hooks/policy-types.ts).

E2E-Teststruktur

Die E2E-Hilfsmittel verwenden

FixtureEnv – isolierte Umgebung pro Test:
createFixtureEnv() registriert die afterEach-Bereinigung automatisch. runHook – das Binary aufrufen:
Payloads – vorgefertigte Nutzlast-Factories:

Einen E2E-Test schreiben

E2E-Antwortformate

Vitest-Konfiguration

E2E-Tests verwenden vitest.config.e2e.mts mit:
  • environment: "node" – keine Browser-Globals erforderlich
  • pool: "forks" – echte Prozessisolierung (Tests starten Subprozesse)
  • testTimeout: 20_000 – 20 Sekunden pro Test (Binary-Start + Hook-Auswertung)
Der forks-Pool ist wichtig: Thread-basierte Worker teilen sich globalThis, was Konflikte mit Tests verursachen kann, die Subprozesse starten. Prozessbasierte Forks vermeiden dieses Problem.

CI

Der vollständige CI-Durchlauf (bun run lint && bunx tsc --noEmit && bun run test:run && bun run build) muss vor dem Mergen erfolgreich abgeschlossen werden. Die E2E-Suite läuft als separater CI-Job parallel dazu. Siehe Contributing für die vollständige Checkliste vor dem Mergen.