मुख्य सामग्री पर जाएं
failproofai के दो परीक्षण सेट हैं: यूनिट परीक्षण (तेज़, मॉक किए गए) और end-to-end परीक्षण (असली subprocess आमंत्रण)।

परीक्षण चलाना


यूनिट परीक्षण

यूनिट परीक्षण __tests__/ में रहते हैं और Vitest के साथ jsdom का उपयोग करते हैं।

नीति यूनिट परीक्षण लिखना


End-to-end परीक्षण

E2E परीक्षण असली failproofai बाइनरी को subprocess के रूप में आमंत्रित करते हैं, JSON पेलोड को stdin में पाइप करते हैं, और stdout आउटपुट और exit कोड पर assertion करते हैं। यह उस संपूर्ण एकीकरण पथ को परीक्षण करता है जो Claude Code उपयोग करता है।

सेटअप

E2E परीक्षण रेपो स्रोत से सीधे बाइनरी चलाते हैं। पहली बार चलाने से पहले, CJS बंडल बनाएं जो कस्टम हुक फाइलें 'failproofai' से आयात करते समय उपयोग करती हैं:
फिर परीक्षण चलाएं:
जब भी आप सार्वजनिक हुक API (src/hooks/custom-hooks-registry.ts, src/hooks/policy-helpers.ts, या src/hooks/policy-types.ts) को परिवर्तित करें, dist/ को पुनः बनाएं।

E2E परीक्षण संरचना

E2E सहायकों का उपयोग करना

FixtureEnv - प्रति-परीक्षण अलग पर्यावरण:
createFixtureEnv() स्वचालित रूप से afterEach क्लीनअप पंजीकृत करता है। runHook - बाइनरी को आमंत्रित करें:
Payloads - तैयार पेलोड फैक्ट्रीज:

E2E परीक्षण लिखना

E2E प्रतिक्रिया आकार

Vitest कॉन्फ़िग

E2E परीक्षण vitest.config.e2e.mts का उपयोग करते हैं जिसमें है:
  • environment: "node" - कोई ब्राउज़र globals आवश्यक नहीं
  • pool: "forks" - सच्चा प्रक्रिया अलगाव (परीक्षण subprocesses spawn करते हैं)
  • testTimeout: 20_000 - प्रति परीक्षण 20s (बाइनरी स्टार्टअप + हुक eval)
forks पूल महत्वपूर्ण है: thread-आधारित workers globalThis साझा करते हैं, जो subprocess-spawning परीक्षणों में हस्तक्षेप कर सकता है। Process-आधारित forks इससे बचते हैं।

CI

संपूर्ण CI चलाव (bun run lint && bunx tsc --noEmit && bun run test:run && bun run build) को मर्ज करने से पहले पास होना आवश्यक है। E2E सेट एक अलग CI कार्य के रूप में समानांतर में चलता है। पूर्ण प्री-मर्ज चेकलिस्ट के लिए Contributing देखें।