मर्ज करने से पहले AI-जनरेटेड कोड को कैसे वेरिफ़ाई करें

ऐसे कोड को रिव्यू करने की समस्या जो आपने नहीं लिखा

एक AI कोडिंग एजेंट मिनटों में एक काम करने वाला फ़ीचर बना सकता है। बॉटलनेक बदल गया है: अब बाधा यह नहीं है कि कोड कितनी तेज़ी से लिखा जाता है, बल्कि यह है कि कोई कितने भरोसे के साथ कह सकता है कि कोड वही करता है जो उसे करना चाहिए था। एक बड़े डिफ़ को ध्यान से पढ़ने में उसे जनरेट करने से ज़्यादा समय लगता है।

टाइप चेक्स और यूनिट टेस्ट्स पुष्टि करते हैं कि कोड वही करता है जो इसे करने के लिए लिखा गया था। वे आपको यह नहीं बता सकते कि डिप्लॉय किया गया एप्लिकेशन अभी भी काम करता है या नहीं, क्योंकि वे कभी उसे खोलते ही नहीं। यही वह गैप है जहां AI-जनरेटेड रिग्रेशन वास्तव में रहते हैं।

लूप, तीन कमांड्स में

ओपन-सोर्स TestSprite CLI इंस्टॉल करें — मुफ़्त, Apache-2.0, Node 20.19+, 22.13+, या 24+:

npm install -g @testsprite/testsprite-cli
testsprite setup

फिर लूप। जिस व्यवहार को आप गारंटीड चाहते हैं उसका वर्णन करें, इसे एक वास्तविक ब्राउज़र के विरुद्ध चलाएं, और एग्ज़िट कोड से फ़ैसला पढ़ें:

# 1 — create the test and run it
testsprite test create --project prj_abc123 --type frontend \
  --plan-from ./checkout-flow.plan.json --run --wait --output json
#   → exit 1: the run failed

# 2 — pull ONE self-consistent failure bundle
testsprite test failure get test_3a9f21c7 --out ./.testsprite/failure

# 3 — fix the code, then replay the same test
testsprite test rerun test_3a9f21c7 --wait --output json
#   → exit 0: passed

चरण दो का बंडल वह हिस्सा है जो मायने रखता है। इसमें फेल हुआ स्टेप, उसके पड़ोसी स्टेप्स, स्क्रीनशॉट्स, DOM स्नैपशॉट्स, टेस्ट सोर्स, एक रूट-कॉज़ हाइपोथिसिस, और एक अनुशंसित फ़िक्स टारगेट शामिल हैं — सभी एक ही स्नैपशॉट आईडी साझा करते हुए। CLI दो अलग-अलग रन्स से डेटा को जोड़ने से इनकार करता है, इसलिए एक एजेंट कभी भी ऐसे कॉन्टेक्स्ट पर तर्क नहीं करता जो एप्लिकेशन की दो अलग-अलग स्थितियों से इकट्ठा किया गया हो।

एक टिकाऊ सुइट एक बड़े कॉन्टेक्स्ट विंडो से बेहतर क्यों है

हर टेस्ट जो पास होता है, वह सुरक्षित हो जाता है। अगली बार जब एजेंट कोडबेस को छूता है, तो वह आवश्यकता अभी भी जांची जा रही होती है — चाहे वह वर्तमान बातचीत में कहीं भी हो या न हो।

यही बाहरी वेरिफ़िकेशन के लिए संरचनात्मक तर्क है। एक कॉन्टेक्स्ट विंडो वह रखती है जिसके बारे में एजेंट अभी सोच रहा है। एक टेस्ट सुइट वह हर आवश्यकता रखती है जिसे प्रोजेक्ट ने कभी सही किया है, और यह उन्हें सत्रों में, एजेंट्स में, और उन महीनों में रखती रहती है जब किसी को याद नहीं रहता कि कोई खास एज केस क्यों मायने रखता था।

अपने एजेंट को यह खुद करने के लिए सेटअप करें

आपको एक वेब पेज और अपने कोडिंग एजेंट के बीच कमांड्स को रिले नहीं करना चाहिए। एक सेटअप कमांड रिपॉज़िटरी में एक स्किल फ़ाइल इंस्टॉल करता है जो लूप का वर्णन उस रूप में करती है जिसे एक एजेंट वास्तव में समझता है:

TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude

समर्थित हार्नेस हैं claude, codex, cursor, cline, antigravity, kiro, windsurf, और copilot। इंस्टॉलेशन पूरी तरह से लोकल है। उसके बाद, एजेंट को पता होता है कि हर सत्र में फिर से बताए बिना टेस्ट्स को कैसे बनाना, चलाना, और ट्राइएज करना है।

ऐसे कमांड पर एक टर्न खर्च करने से पहले जो एनवायरनमेंटल कारणों से फेल हो जाएगा, एनवायरनमेंट जांचें:

testsprite doctor    # CLI and Node versions, profile, credentials, connectivity

पहले क्या वेरिफ़ाई करें

हर चीज़ एंड-टू-एंड टेस्ट की हकदार नहीं है। एक AI एजेंट के तहत तेज़ी से बदलते कोडबेस में, सबसे अधिक मूल्य वाला कवरेज संकीर्ण होता है:

1. वे फ़्लोज़ जो राजस्व जनरेट करते हैं। साइन-अप, चेकआउट, और बिलिंग। यहां एक रिग्रेशन तुरंत पैसे खर्च करवाता है और अक्सर यूनिट टेस्ट्स में अदृश्य होता है।

2. ऑथेंटिकेशन से जुड़ी कोई भी चीज़। सेशन हैंडलिंग, लॉगिन के बाद रीडायरेक्ट, और परमिशन बाउंड्रीज़ ही वे जगहें हैं जहां एक प्रशंसनीय दिखने वाला रीफ़ैक्टर सबसे ज़्यादा नुकसान करता है।

3. फॉर्म्स और वेलिडेशन। वर्णन करना सस्ता है, और जब एक कंपोनेंट लाइब्रेरी अपग्रेड होती है या एक फ़ील्ड का नाम बदला जाता है तो टूटने की संभावना असमान रूप से ज़्यादा होती है।

4. आपके शिप किए गए आख़िरी तीन बग्स। एक फ़िक्स के बाद लिखा गया रिग्रेशन टेस्ट किसी भी सुइट में सबसे ज़्यादा उपज देने वाला एकल टेस्ट होता है।

अगर आप चाहते हैं कि पहला सेट आपके लिए प्रस्तावित किया जाए, तो एक्सप्लोरेशन उन्हें ड्राफ़्ट कर सकता है। प्रस्तावों को रिव्यू के लिए स्टेज किया जाता है और जब तक आप स्वीकार नहीं करते तब तक आपकी डिस्क पर कुछ नहीं लिखा जाता:

testsprite test plan generate --project prj_abc123
testsprite test plan accept --project prj_abc123           # all of them
testsprite test plan accept --project prj_abc123 --only prop_2 prop_5

जांच को अनिवार्य बनाना

एक वेरिफ़िकेशन स्टेप जो तभी चलता है जब किसी को इसे चलाना याद रहे, वह वेरिफ़िकेशन नहीं है। इसे CI में डालें:

testsprite ci init github

यह TestSprite/testsprite-action@v1 का उपयोग करके .github/workflows/testsprite.yml तैयार करता है, जो हर फेल्योर के लिए PR चेक्स टैब पर एक एरर एनोटेट करता है, जॉब समरी में एक रिज़ल्ट्स टेबल जोड़ता है, एक JUnit रिपोर्ट अपलोड करता है, और — महत्वपूर्ण रूप से — एक आंशिक रन को हरा रिपोर्ट करने के बजाय जॉब को फेल कर देता है।

यह वह पथ है जहां आपका वर्कफ़्लो रन को चलाता है। TestSprite एक GitHub App के रूप में भी इंस्टॉल होता है जो आपकी पाइपलाइन द्वारा पहले से जनरेट किए गए डिप्लॉयमेंट इवेंट्स को सुनता है और परिणामों को पुल रिक्वेस्ट पर वापस कमेंट करता है, जिसके लिए किसी वर्कफ़्लो फ़ाइल और किसी रिपॉज़िटरी बदलाव की बिल्कुल ज़रूरत नहीं है।

किसी भी अन्य CI सिस्टम में CLI को एनवायरनमेंट में केवल एक API कुंजी चाहिए:

export TESTSPRITE_API_KEY="$TESTSPRITE_API_KEY"
testsprite test run --all --project prj_abc123 --wait \
  --report junit --report-file testsprite-junit.xml \
  --summary-file testsprite-summary.json

शाखा बनाने लायक एग्ज़िट कोड्स

कोड 129, 130, और 143 का मतलब है कि प्रोसेस को एक सिग्नल द्वारा बाधित किया गया था (128 प्लस सिग्नल नंबर), न कि यह कि कोई टेस्ट फेल हुआ — किसी रन को टूटा हुआ रिपोर्ट करने से पहले इसे अलग करना ज़रूरी है।

अक्सर पूछे जाने वाले प्रश्न