Skip to main content
failproofai verfügt über zwei Test-Suites: Unit-Tests (schnell, gemockt) und End-to-End-Tests (echte Subprocess-Aufrufe).

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 Subprocess 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.

Setup

E2E-Tests führen das Binary direkt aus dem Repository-Quellcode aus. Vor dem ersten Durchlauf muss das CJS-Bundle gebaut werden, das Custom-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-Hilfsfunktionen verwenden

FixtureEnv – isolierte Testumgebung pro Test:
createFixtureEnv() registriert die afterEach-Bereinigung automatisch. runHook – das Binary aufrufen:
Payloads – vorgefertigte Payload-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 Subprocesse)
  • testTimeout: 20_000 – 20 Sekunden pro Test (Binary-Start + Hook-Auswertung)
Der forks-Pool ist wichtig: Thread-basierte Workers teilen sich globalThis, was bei Tests, die Subprocesse starten, zu Konflikten führen kann. Prozessbasierte Forks vermeiden dies.

CI

Der vollständige CI-Durchlauf (bun run lint && bunx tsc --noEmit && bun run test:run && bun run build) muss bestanden werden, bevor ein Merge möglich ist. Die E2E-Suite läuft als separater CI-Job parallel dazu. Siehe Contributing für die vollständige Prüfliste vor dem Merge.