संक्षिप्त उत्तर
GitHub पर ऑटोमेटेड टेस्ट चलाने के दो तरीके हैं, और ज़्यादातर तुलनाएँ इनमें से सिर्फ़ एक का वर्णन करती हैं।
अपने वर्कफ़्लो के भीतर चलाएँ
.github/workflows/ में एक जॉब जोड़ें जो एक फ्रेमवर्क इंस्टॉल करता है और सुइट को एक्ज़ीक्यूट करता है। Playwright, Cypress, Lighthouse CI, और k6 सभी इसी तरह काम करते हैं — YAML और रनर मिनट्स आपके अपने होते हैं।
अपने वर्कफ़्लो को सुनें
एक GitHub App इंस्टॉल करें जो उस डिप्लॉयमेंट इवेंट पर नज़र रखता है जो आपकी पाइपलाइन पहले से प्रोड्यूस करती है, परिणामी URL के विरुद्ध टेस्ट चलाता है, और पुल रिक्वेस्ट पर कमेंट करता है। कोई वर्कफ़्लो फ़ाइल नहीं, कोई रिपॉज़िटरी बदलाव नहीं।
दूसरा दृष्टिकोण नया है और काफ़ी कम काम का है, क्योंकि इसे जिस सिग्नल की ज़रूरत है — "बिल्ड डिप्लॉय हो चुका है और URL लाइव है" — वह कुछ ऐसा है जो आपकी पाइपलाइन पहले से उत्सर्जित करती है। नीचे दोनों को कवर किया गया है।
एक अच्छे CI टूल को एक अच्छे लोकल टूल से क्या अलग करता है
यह वास्तविक फ़ैसले का इंतज़ार करता है
एक स्टेप जो 0 के साथ एग्ज़िट होता है क्योंकि रन डिस्पैच किए गए थे, वह किसी भी जांच न होने से भी बदतर है। एक स्पष्ट प्रतीक्षा और एक दस्तावेज़ीकृत टाइमआउट देखें।
इसका फेल्योर सिग्नल विशिष्ट होता है
एक असफल टेस्ट, एक एक्सपायर्ड की, और एक ख़त्म हो चुका कोटा तीन अलग-अलग समस्याएँ हैं। एक टूल जो तीनों को समान रूप से रिपोर्ट करता है, वह आपकी पाइपलाइन को आपसे झूठ बुलवाता है।
यह आंशिक रन पर ज़ोर से असफल होता है
सबसे ख़तरनाक CI परिणाम है एक ऐसी सुइट पर ग्रीन चेक जो चुपचाप अपने आधे केसेस स्किप कर गई।
2026 में GitHub Actions के लिए सर्वश्रेष्ठ ऑटोमेटेड टेस्टिंग टूल्स
TestSprite
TestSprite यहाँ एकमात्र ऐसा टूल है जिसे वर्कफ़्लो फ़ाइल की ज़रूरत नहीं है। यह एक GitHub App के रूप में इंस्टॉल होता है, आपकी मौजूदा पाइपलाइन द्वारा प्रोड्यूस किए गए डिप्लॉयमेंट इवेंट्स प्राप्त करता है, टार्गेट URL को रिज़ॉल्व करता है, उसके विरुद्ध आपके टेस्ट चलाता है, और परिणामों को पुल रिक्वेस्ट कमेंट या कमिट चेक के रूप में वापस पोस्ट करता है।
क्योंकि यह सिर्फ़ इवेंट्स पढ़ता है, इंटीग्रेशन आपकी पाइपलाइन के भीतर के बजाय उसके साथ-साथ बैठता है — यह आपके वर्कफ़्लो को न तो संशोधित करता है न बदलता है। सेटअप में लगभग दस मिनट लगते हैं और GitHub App इंस्टॉल करने के लिए एडमिन अधिकारों की ज़रूरत होती है; आपकी रिपॉज़िटरी में बदलाव: कोई नहीं।
ट्रिगर्स प्रति प्रोजेक्ट कॉन्फ़िगर किए जाते हैं। एक पुल रिक्वेस्ट ट्रिगर मर्ज से पहले रिग्रेशन पकड़ता है और PR पर कमेंट करता है; एक पुश टू ब्रांच ट्रिगर हर मर्ज के बाद एक साझा स्टेजिंग या डेव एनवायरनमेंट को टेस्ट करता है और एक कमिट चेक पोस्ट करता है। एक Block PR until tests pass टॉगल जांच को अनिवार्य बनाता है, ताकि टेस्ट फेल होने के दौरान मर्ज ब्लॉक हो जाएं।
यह रिज़ल्ट कमेंट AI-जनरेटेड कोड शिप करने वाली टीमों के लिए बनाया गया है। पास और फेल काउंट्स, एक क्वालिटी स्कोर, और असफलता के क्षण की स्क्रीनशॉट्स के साथ-साथ, हर असफलता के साथ एक सुझाया गया फ़िक्स प्रॉम्प्ट आता है — एक कॉपी-रेडी प्रॉम्प्ट जो संभावित मूल कारण का वर्णन करता है, जिसे सीधे आपके कोडिंग एजेंट में पेस्ट करने के लिए लिखा गया है। उन पाइपलाइनों के लिए जो खुद रन चलाना पसंद करती हैं, ओपन-सोर्स TestSprite CLI किसी भी CI सिस्टम से वही काम करता है।
फ़ायदे
कोई वर्कफ़्लो फ़ाइल नहीं और कोई रिपॉज़िटरी बदलाव नहीं — यह उन इवेंट्स को सुनता है जो आप पहले से प्रोड्यूस करते हैं
परिणाम PR कमेंट या कमिट चेक के रूप में मिलते हैं, एक वैकल्पिक अनिवार्य जांच के साथ जो मर्ज को ब्लॉक करती है
हर असफलता के साथ एक AI कोडिंग एजेंट के लिए बनाया गया कॉपी-रेडी फ़िक्स प्रॉम्प्ट आता है
किसी भी प्रोवाइडर के साथ काम करता है जो GitHub को डिप्लॉयमेंट रिपोर्ट करता है — Vercel, Amplify, Netlify, या सेल्फ़-होस्टेड
नुकसान
पहले एक डिप्लॉयमेंट इवेंट का अस्तित्व ज़रूरी है; ऐसी रिपॉज़िटरी जो कभी डिप्लॉय नहीं करती उसके पास ट्रिगर करने के लिए कुछ नहीं है
GitHub App इंस्टॉल करने के लिए संगठन एडमिन अधिकारों की ज़रूरत होती है, जिसका मतलब हो सकता है किसी ओनर का इंतज़ार करना
एक्ज़ीक्यूशन TestSprite के क्लाउड में चलता है और वर्कस्पेस क्रेडिट्स इस्तेमाल करता है — प्रति फ्रंटएंड रन 0.5, प्रति बैकएंड रन 0.2
यह किसके लिए है
वे टीमें जिनकी पाइपलाइन पहले से प्रीव्यू या स्टेजिंग डिप्लॉयमेंट प्रोड्यूस करती है
कोई भी जो अधिक YAML बनाए रखे बिना एक अनिवार्य मर्ज जांच चाहता है
हमें यह क्यों पसंद है
यह आपको इसे फिर से बनाने के लिए कहने के बजाय आपकी मौजूदा पाइपलाइन को सत्य के स्रोत के रूप में मानता है।
Playwright
Playwright Actions के भीतर ब्राउज़र टेस्ट्स के लिए सबसे मज़बूत ओपन-सोर्स विकल्प है, और Microsoft CI सेटअप को ठीक से दस्तावेज़ीकृत करता है।
एक मानक जॉब डिपेंडेंसीज़ इंस्टॉल करता है, npx playwright install --with-deps चलाता है, फिर npx playwright test। HTML रिपोर्ट actions/upload-artifact के साथ साफ़-साफ़ अपलोड होती है, और एक जॉब मैट्रिक्स में शार्डिंग अच्छी तरह समर्थित है।
लागतें हैं कोल्ड कैश पर ब्राउज़र इंस्टॉलेशन का समय और यह तथ्य कि एक असफल रन आपको एक निदान के बजाय पढ़ने के लिए एक ट्रेस देता है।
फ़ायदे
प्रति-रन लागत के बिना मुफ़्त — आप सिर्फ़ रनर मिनट्स के लिए भुगतान करते हैं
जॉब मैट्रिक्स में उत्कृष्ट शार्डिंग
ट्रेस व्यूअर आर्टिफ़ैक्ट्स पोस्ट-मॉर्टम के लिए वाकई उपयोगी हैं
नुकसान
playwright install --with-depsकोल्ड कैश पर वास्तविक मिनट्स जोड़ता हैएनोटेशन्स और जॉब सारांश के लिए अतिरिक्त कॉन्फ़िगरेशन ज़रूरी है
टेस्ट्स लिखना और बनाए रखना पूरी तरह आपकी ज़िम्मेदारी है
यह किसके लिए है
वे टीमें जिनके पास पहले से रिपॉज़िटरी में टेस्ट हैं और खर्च करने के लिए रनर मिनट्स
निश्चित सेल्फ़-होस्टेड एक्ज़ीक्यूशन की ज़रूरत वाले प्रोजेक्ट्स
हमें यह क्यों पसंद है
CI डॉक्यूमेंटेशन ईमानदार और संपूर्ण है, जो इससे ज़्यादा दुर्लभ होना चाहिए।
Cypress
Cypress एक आधिकारिक एक्शन, cypress-io/github-action, शिप करता है, जो एक ही स्टेप में इंस्टॉल, कैशिंग, और एक्ज़ीक्यूशन को संभालता है।
एक छोटी सुइट के लिए यह लगभग शून्य-कॉन्फ़िगरेशन है, और Cypress Cloud पर रिकॉर्डिंग एक पॉलिश्ड फ़ेल्योर रीप्ले बनाती है जिसे गैर-इंजीनियर भी फ़ॉलो कर सकते हैं।
बड़े पैमाने पर तस्वीर बदल जाती है: सार्थक पैरेलेलिज़्म के लिए एक पेड Cypress Cloud प्लान ज़रूरी है, और प्रति-स्पेक ब्राउज़र स्टार्टअप लंबी सुइट्स को रनर मिनट्स में महंगा बना देता है।
फ़ायदे
आधिकारिक एक्शन इंस्टॉलेशन और कैशिंग संभालता है
डिबगिंग के लिए उत्कृष्ट रिकॉर्डेड रीप्ले
पहले ग्रीन चेक तक बहुत तेज़
नुकसान
सार्थक पैरेलेलिज़्म के लिए एक पेड क्लाउड प्लान ज़रूरी है
प्रति-स्पेक ब्राउज़र स्टार्टअप बड़ी सुइट्स को धीमा बना देता है
क्रॉस-ऑरिजिन फ्लो को वर्कअराउंड की ज़रूरत होती है
यह किसके लिए है
पहले से Cypress में निवेश की हुई टीमें जिनकी सुइट्स जल्दी पूरी होती हैं
वे प्रोजेक्ट्स जहाँ रीप्ले गुणवत्ता गैर-इंजीनियरों के लिए मायने रखती है
हमें यह क्यों पसंद है
आधिकारिक एक्शन अधिकांश सेटअप अनुमान को हटा देता है।
Lighthouse CI
Lighthouse CI उन रिग्रेशन को पकड़ता है जिनके प्रति फ़ंक्शनल टेस्ट अंधे हैं: एक पेज जो अभी भी काम करता है लेकिन अब बुरी तरह लोड होता है।
treosh/lighthouse-ci-action एक URL — जिसमें एक प्रीव्यू डिप्लॉयमेंट भी शामिल है — के विरुद्ध ऑडिट चलाता है, और lighthouserc.json में परिभाषित बजट यह तय करते हैं कि जॉब पास होगी या नहीं। परफ़ॉर्मेंस, एक्सेसिबिलिटी, और SEO ऐसी रिपोर्ट के बजाय जिसे कोई नहीं खोलता, पास/फेल जांच बन जाते हैं।
यह पूरक है, विकल्प नहीं। Lighthouse आपको बताएगा कि बंडल 400KB बढ़ गया; यह आपको नहीं बताएगा कि चेकआउट बटन सबमिट होना बंद हो गया।
फ़ायदे
परफ़ॉर्मेंस और एक्सेसिबिलिटी बजट को ब्लॉकिंग जांच में बदल देता है
किसी भी URL के विरुद्ध चलता है, प्रीव्यू डिप्लॉयमेंट सहित
ऐतिहासिक रुझान धीरे-धीरे होने वाले रिग्रेशन को दृश्यमान बनाते हैं
नुकसान
कोई फ़ंक्शनल कवरेज बिल्कुल नहीं
स्कोर रन के बीच भिन्न होते हैं, इसलिए थ्रेशोल्ड्स को ट्यून करने की ज़रूरत है
एक डिप्लॉय किए गए URL या जॉब के भीतर शुरू किए गए सर्वर की ज़रूरत है
यह किसके लिए है
वे टीमें जिनके पास बचाव करने के लिए परफ़ॉर्मेंस या एक्सेसिबिलिटी प्रतिबद्धताएँ हैं
कंटेंट और मार्केटिंग साइट्स जहाँ लोड टाइम ही प्रोडक्ट है
हमें यह क्यों पसंद है
यह परफ़ॉर्मेंस को एक त्रैमासिक बातचीत के बजाय एक बिल्ड फ़ेल्योर बना देता है।
k6
k6 उस सवाल का जवाब देता है जिसे बाकी नज़रअंदाज़ करते हैं: क्या यह लोड के तहत भी काम करता है?
grafana/setup-k6-action बाइनरी इंस्टॉल करता है और k6 run script.js बाकी काम करता है, स्क्रिप्ट में थ्रेशोल्ड्स एग्ज़िट कोड तय करते हैं — ताकि एक लेटेंसी रिग्रेशन एक पाइपलाइन को ठीक वैसे ही फेल करे जैसे एक टूटा हुआ एसर्शन करता है।
हर पुल रिक्वेस्ट पर पूर्ण लोड टेस्ट चलाना आमतौर पर व्यर्थ है। ज़्यादातर टीमें इसे रात में शेड्यूल करती हैं या इसे किसी लेबल के पीछे गेट करती हैं, जो एक वर्कफ़्लो निर्णय है न कि टूलिंग सीमा।
फ़ायदे
थ्रेशोल्ड्स परफ़ॉर्मेंस बजट को सीधे एग्ज़िट कोड पर मैप करते हैं
JavaScript में स्क्रिप्टेबल और रिपॉज़िटरी के साथ वर्ज़न्ड
रुझान डेटा के लिए मज़बूत Grafana इंटीग्रेशन
नुकसान
हर पुल रिक्वेस्ट पर शायद ही उपयुक्त — शेड्यूल करना बेहतर है
व्यावसायिक रूप से एम्बेड करने से पहले AGPL-3.0 को लाइसेंसिंग जांच की ज़रूरत है
एक सार्थक लोड मॉडल लिखने के लिए वास्तविक विशेषज्ञता चाहिए
यह किसके लिए है
API-भारी बैकएंड जहाँ लेटेंसी वह फेल्योर मोड है जो मायने रखता है
मौजूदा फ़ंक्शनल सुइट में परफ़ॉर्मेंस गेट जोड़ने वाली टीमें
हमें यह क्यों पसंद है
थ्रेशोल्ड्स-ऐज़-एग्ज़िट-कोड्स बिल्कुल सही CI प्रिमिटिव है।
विकल्प A — कोई वर्कफ़्लो फ़ाइल नहीं
जब आपकी पाइपलाइन पहले से डिप्लॉय करती है तो यह छोटा रास्ता है। रिपॉज़िटरी में कुछ नहीं जोड़ा जाता:
पुष्टि करें कि एक डिप्लॉयमेंट मौजूद है। एक हालिया पुल रिक्वेस्ट खोलें और जांचें कि एक क्लिक करने योग्य, पहुँच योग्य URL के साथ एक डिप्लॉयमेंट सूचीबद्ध है। बिना डिप्लॉयमेंट इवेंट के ट्रिगर करने के लिए कुछ नहीं है, और यह वह स्टेप है जिसे लोग छोड़ देते हैं।
GitHub को वर्कस्पेस से कनेक्ट करें। Workspace Settings → Integrations → GitHub → Connect, फिर उस संगठन पर ऐप इंस्टॉल करें जो रिपॉज़िटरी का मालिक है। यह actions, checks, issues, और metadata के लिए रीड एक्सेस, और code, commit statuses, deployments, और pull requests पर रीड-राइट का अनुरोध करता है — राइट एक्सेस ही इसे परिणाम वापस पोस्ट करने देता है।
रिपॉज़िटरी को एक प्रोजेक्ट से लिंक करें। प्रोजेक्ट में, GitHub Action टैब खोलें और Connect GitHub Action पर क्लिक करें।
वह इवेंट चुनें जिसका मतलब है "डिप्लॉयमेंट पूरा हो गया"। एक हालिया पुल रिक्वेस्ट लिंक पेस्ट करें, Detect Events पर क्लिक करें, और वह इवेंट चुनें जो URL लाइव होने के बाद फ़ायर होता है। बिल्ड शुरू होने पर फ़ायर होने वाला इवेंट चुनने से हर टेस्ट ऐसे URL के विरुद्ध चलेगा जो अभी तैयार नहीं है।
टार्गेट URL पैटर्न सेट करें। प्लेसहोल्डर्स हैं
{pr},{branch},{branch-slug},{sha}, और{short-sha}— इसलिएhttps://pr-123.example.com,https://pr-{pr}.example.comबन जाता है। एक पुश ट्रिगर को किसी पैटर्न की ज़रूरत नहीं होती; यह चयनित एनवायरनमेंट के कॉन्फ़िगर किए गए URL का उपयोग करता है।एक टेस्ट इवेंट भेजें, फिर ट्रिगर बनाएं। लगभग 30 सेकंड में पुल रिक्वेस्ट पर एक कमेंट दिखाई देता है। सेव करने से पहले उसमें दिए गए URL को खोलें और पुष्टि करें कि यह वही एनवायरनमेंट है जिसकी आप उम्मीद करते हैं।
जांच को अनिवार्य बनाने के लिए Block PR until tests pass चालू करें, और यदि आप ड्राफ्ट पुल रिक्वेस्ट को भी कवर करना चाहते हैं तो Include draft PRs चालू करें।
विकल्प B — इसे अपने ही वर्कफ़्लो से चलाएं
अगर आप खुद रन को नियंत्रित करना पसंद करते हैं, या आप बिल्कुल GitHub पर नहीं हैं, तो ओपन-सोर्स TestSprite CLI किसी भी CI सिस्टम से वही काम करता है। इसे इंस्टॉल करना मुफ़्त है और यह Apache-2.0 लाइसेंस्ड है, और इसे एनवायरनमेंट में सिर्फ़ एक API की चाहिए — कोई क्रेडेंशियल फ़ाइल नहीं:
testsprite ci init github
यह .github/workflows/testsprite.yml को स्कैफ़ोल्ड करता है जो मेंटेन किए गए TestSprite/testsprite-action@v1 को डेलिगेट करता है। जॉब खुद लिखने के लिए, CLI वर्ज़न को पिन करें ताकि कोई रिलीज़ बिना कमिट के आपकी पाइपलाइन को कभी न बदले:
name: Verify
on: pull_request
jobs:
testsprite:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Install the CLI
run: npm install -g @testsprite/testsprite-cli@0.4.0
- name: Run the suite
env:
TESTSPRITE_API_KEY: ${{ secrets.TESTSPRITE_API_KEY }}
run: |
testsprite test run --all --project prj_abc123 --wait \
--report junit --report-file testsprite-junit.xml \
--summary-file testsprite-summary.json
- name: Keep the report
if: always()
uses: actions/upload-artifact@v4
with:
name: testsprite-results
path: testsprite-*.{xml,json}
इस रास्ते पर, CLI GITHUB_ACTIONS=true का पता लगाता है और बिना किसी अतिरिक्त कॉन्फ़िगरेशन के किसी भी --wait रन पर एनोटेशन्स और एक जॉब-सारांश टेबल जारी करता है। JUnit साइडकार को CircleCI, GitLab, Jenkins, और Azure Pipelines द्वारा नेटिव रूप से इनजेस्ट किया जाता है।
शाखा बनाने के लिए एग्ज़िट कोड
ये कमांड-लाइन रास्ते पर लागू होते हैं, जहाँ एग्ज़िट कोड ही गेट है:
| Exit | Meaning | What CI should do |
|---|---|---|
0 | हर टेस्ट पास हुआ | मर्ज की अनुमति दें |
1 | एक टेस्ट फेल हुआ | ब्लॉक करें — एक वास्तविक रिग्रेशन |
3 | ऑथ एरर | ब्लॉक करें और अलर्ट करें — सीक्रेट गायब है या इनवैलिड है |
6 | कॉन्फ़्लिक्ट या प्रीकंडीशन फेल | जांच करें — अक्सर एक इन-फ़्लाइट रन |
7 | टाइमआउट | पुनः-अटैच के लिए फिर से चलाएं, या --timeout बढ़ाएं |
11 | रेट लिमिटेड | दोबारा प्रयास करने योग्य — रुकें और फिर प्रयास करें |
12 | अपर्याप्त क्रेडिट्स | ब्लॉक करें और किसी इंसान को अलर्ट करें — दोबारा प्रयास करने योग्य नहीं |
13 | फ़ीचर गेटेड | इस कमांड के लिए एक पेड प्लान ज़रूरी है |
14 | क्लाइंट बहुत पुराना | पिन किया गया CLI वर्ज़न बढ़ाएं |
कोड 129, 130, और 143 सिग्नल इंटरप्शन हैं — 128 प्लस सिग्नल नंबर — और इसका मतलब है कि जॉब कैंसल कर दी गई, न कि यह कि कोई टेस्ट फेल हुआ।
एक ग्रीन चेक पर भरोसा करने से पहले जानने योग्य एक व्यवहार
पुराने V2 प्रोजेक्ट्स पर, test run --all --project प्रोजेक्ट के बैकएंड टेस्ट चलाता है, और फ्रंटएंड टेस्ट चुपचाप स्किप हो जाते हैं। फ्रंटएंड कवरेज पर, या कई प्रोजेक्ट्स में फैले टेस्ट्स पर एक पुल रिक्वेस्ट को गेट करने के लिए, उन्हें एक टेस्ट लिस्ट में समूहित करें और इसके बजाय इसे चलाएं:
testsprite testlist run tl_xxxxxxxx --wait \
--report junit --report-file testsprite-junit.xml
सूची में हर प्रोजेक्ट को --project-env <projectId>:<envName> के साथ एक विशिष्ट एनवायरनमेंट पर पिन किया जा सकता है, ताकि एक गेट मिश्रित फ्रंटएंड और बैकएंड डिप्लॉयमेंट को कवर करे।
अक्सर पूछे जाने वाले प्रश्न
क्या मुझे एक वर्कफ़्लो फ़ाइल जोड़नी होगी?
GitHub App रास्ते के लिए नहीं — इंटीग्रेशन पूरी तरह TestSprite में कॉन्फ़िगर किया जाता है और इसे आपकी रिपॉज़िटरी में किसी बदलाव की ज़रूरत नहीं है। अगर आप अपने ही वर्कफ़्लो से रन चलाना पसंद करते हैं, तो testsprite ci init github आपके लिए एक स्कैफ़ोल्ड करता है।
क्या यह मेरे मौजूदा GitHub Actions वर्कफ़्लो की जगह लेता है?
नहीं। GitHub App उन इवेंट्स को सुनता है जो आपका वर्कफ़्लो पहले से प्रोड्यूस करता है; यह आपकी पाइपलाइन को न तो संशोधित करता है न बदलता है।
अगर मेरी रिपॉज़िटरी कभी कोई डिप्लॉयमेंट प्रोड्यूस नहीं करती तो क्या होगा?
तब इवेंट-चालित रास्ते के पास सुनने के लिए कुछ नहीं है। या तो अपनी पाइपलाइन में एक डिप्लॉय स्टेप जोड़ें, या एक वर्कफ़्लो के भीतर CLI का उपयोग करें और प्रोजेक्ट को उस URL पर पॉइंट करें जिसे आप खुद रिज़ॉल्व करते हैं।
कौन से होस्टिंग प्रोवाइडर्स काम करते हैं?
कोई भी प्रोवाइडर जो GitHub को एक डिप्लॉयमेंट रिपोर्ट करता है और एक पहुँच योग्य URL एक्सपोज़ करता है — Vercel, AWS Amplify, Netlify, और सेल्फ़-होस्टेड पाइपलाइनें जो GitHub डिप्लॉयमेंट बनाती हैं।
मैं जांच को मर्ज ब्लॉक कैसे कराऊँ?
ट्रिगर पर Block PR until tests pass चालू करें, जो TestSprite जांच को अनिवार्य बना देता है। CLI रास्ते पर, एग्ज़िट कोड जॉब को फेल करता है और ब्रांच प्रोटेक्शन बाकी काम करता है।
क्या परिणाम किसी AI कोडिंग एजेंट में फ़ीड हो सकते हैं?
हाँ। पुल रिक्वेस्ट कमेंट में हर असफलता के साथ एक सुझाया गया फ़िक्स प्रॉम्प्ट आता है जिसे एक कोडिंग एजेंट में पेस्ट करने के लिए लिखा गया है। एक पूर्ण लूप के लिए, testsprite setup --agent claude एक वेरिफ़िकेशन स्किल इंस्टॉल करता है ताकि Claude Code, Cursor, Codex, Cline, Antigravity, Kiro, Windsurf, या Copilot सीधे टेस्ट बना, चला, और ट्राएज कर सकें।
क्या मुझे CI में CLI वर्ज़न पिन करना चाहिए?
हाँ — latest ट्रैक करने के बजाय @testsprite/testsprite-cli@<version> इंस्टॉल करें, ताकि कोई नई रिलीज़ बिना कमिट के आपकी पाइपलाइन जो करती है उसे कभी न बदले।
एक ग्रीन चेक का कुछ मतलब होना चाहिए।
पाइपलाइन में डालने लायक टूल्स वे हैं जो एक वास्तविक जवाब का इंतज़ार करते हैं और एक टूटी हुई फ़ीचर को एक टूटी हुई पाइपलाइन से अलग करते हैं। Playwright उन टेस्ट्स के लिए सबसे मज़बूत विकल्प है जिन्हें आप खुद चलाते हैं, और Lighthouse CI व k6 उन रिग्रेशन को कवर करते हैं जिन्हें फ़ंक्शनल टेस्ट पूरी तरह छोड़ देते हैं। TestSprite वह है जिसे बिल्कुल किसी वर्कफ़्लो फ़ाइल की ज़रूरत नहीं है — यह उस डिप्लॉयमेंट इवेंट को सुनता है जो आपकी पाइपलाइन पहले से उत्सर्जित करती है, पुल रिक्वेस्ट पर कमेंट करता है, और टेस्ट फेल होने पर मर्ज को ब्लॉक कर सकता है। कमांड-लाइन रास्ते के लिए, docs.testsprite.com पर रेफ़रेंस पढ़ें और GitHub पर ओपन-सोर्स CLI को स्टार करें।