Vai al contenuto principale
failproofai ha due suite di test: test unitari (veloci, con mock) e test end-to-end (invocazioni reali di subprocess).

Esecuzione dei test


Test unitari

I test unitari si trovano in __tests__/ e utilizzano Vitest con jsdom.

Scrivere un test unitario per una policy


Test end-to-end

I test E2E invocano il vero binario failproofai come subprocess, inviano un payload JSON su stdin e verificano l’output su stdout e il codice di uscita. Questo testa il percorso di integrazione completo che Claude Code utilizza.

Setup

I test E2E eseguono il binario direttamente dal codice sorgente del repository. Prima della prima esecuzione, compila il bundle CJS che i file di custom hook utilizzano quando importano da 'failproofai':
Quindi esegui i test:
Ricompila dist/ ogni volta che modifichi la public hook API (src/hooks/custom-hooks-registry.ts, src/hooks/policy-helpers.ts, o src/hooks/policy-types.ts).

Struttura del test E2E

Utilizzo degli helper E2E

FixtureEnv - ambiente isolato per ogni test:
createFixtureEnv() registra la pulizia afterEach automaticamente. runHook - invoca il binario:
Payloads - factory di payload pronti all’uso:

Scrivere un test E2E

Forme di risposta E2E

Config Vitest

I test E2E utilizzano vitest.config.e2e.mts con:
  • environment: "node" - nessun browser global necessario
  • pool: "forks" - vera isolazione dei processi (i test spawnnano subprocess)
  • testTimeout: 20_000 - 20s per test (avvio binario + hook eval)
Il pool forks è importante: i worker basati su thread condividono globalThis, il che può interferire con i test che spawnnano subprocess. I fork basati su processo evitano questo problema.

CI

L’esecuzione CI completa (bun run lint && bunx tsc --noEmit && bun run test:run && bun run build) è richiesta prima del merge. La suite E2E viene eseguita come job CI separato in parallelo. Vedi Contributing per la lista di controllo completa pre-merge.