अपने CI/CD पाइपलाइन को एआई टेस्टिंग सीएलआई से गेट करें।
testsprite को GitHub Actions, GitLab CI, या किसी भी ऐसी पाइपलाइन में डालें जो शेल स्टेप चला सकती है। यह एक एनवायरनमेंट वेरिएबल से ऑथेंटिकेट करता है, आपके सुइट को एक असली डिप्लॉय किए गए एनवायरनमेंट पर चलाता है, और एक स्थिर, पूर्वानुमानित कोड के साथ एग्ज़िट करता है — ताकि टूटा हुआ बिल्ड बिल्ड को फेल करे, अगली स्टैंडअप मीटिंग को नहीं।
किसी भी CI, किसी भी रनर, किसी भी शेल में चलता है
डिज़ाइन से ही नॉन-इंटरैक्टिव
TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude — कोई प्रॉम्प्ट नहीं, कोई ब्राउज़र लॉगिन नहीं, हेडलेस रनर में भी काम करता है।
एक स्टेप, किसी भी पाइपलाइन में
testsprite test run --all --project <id> --wait --output json को एक ही CI स्टेप के रूप में चलाएँ — JSON को पार्स करें, या बस एग्ज़िट कोड जाँच लें।
पूर्वानुमानित एग्ज़िट कोड
स्थिर, दस्तावेज़ीकृत एग्ज़िट कोड का मतलब है कि आपकी पाइपलाइन किसी असली नतीजे पर मर्ज को गेट कर सकती है, न कि क्या हुआ यह अंदाज़ा लगाने के लिए फ्री-टेक्स्ट लॉग पार्स करके।
कमिट करने से पहले ड्राई-रन करें
--dry-run टेस्ट डेटा के साथ ऑफ़लाइन आपकी पाइपलाइन लॉजिक को चलाकर देखता है, ताकि आप स्टेप को किसी लाइव एनवायरनमेंट पर लगाने से पहले सही से जोड़ सकें।
# .github/workflows/verify.yml
- name: Verify with TestSprite
env:
TESTSPRITE_API_KEY: ${{ secrets.TESTSPRITE_API_KEY }}
run: |
npm install -g @testsprite/testsprite-cli
testsprite setup --from-env --yes
testsprite test run --all --project prj_8f2a --wait --output json
# exits non-zero on a real failure — the merge gate fails with it
मर्ज गेट को मायने रखने दें
एक बिल्ड जो पास हो जाए क्योंकि उसने कभी असल में जाँचा ही नहीं, वह पासिंग बिल्ड नहीं है। हर पाइपलाइन रन आपके असली डिप्लॉय किए गए एनवायरनमेंट को टेस्ट करता है — असली ब्राउज़र, असली API कॉल — और किसी असली वजह से फेल होता है।
पाइपलाइन के हर चरण के लिए बनाया गया
PR, नाइटली, या रिलीज़
हर PR पर पूरा सुइट चलाएँ, नाइटली एक छोटा स्मोक सेट, या रिलीज़ से पहले सब कुछ — वही कमांड, बस अलग --project और प्लान।
बैच रीरन
testsprite test rerun --all --project <id> पूरी पाइपलाइन को फिर से ट्रिगर किए बिना, अस्थिर दिखने वाले रन के बाद सब कुछ फिर से वेरिफाई करता है।
मुफ़्त कम्युनिटी वर्ज़न
एक मुफ़्त कम्युनिटी वर्ज़न देता है, जिससे यह सबके लिए सुलभ बनता है।
दो रन का डिफ़
testsprite test diff <runId1> <runId2> बताता है कि पास होने वाले बिल्ड और फेल होने वाले बिल्ड के बीच असल में क्या बदला।
दुनिया भर के व्यवसायों द्वारा विश्वसनीय
"टेस्टस्प्राइट समृद्ध टेस्ट केस जनरेशन, स्पष्ट संरचना और पढ़ने में आसान कोड प्रदान करता है। यह नए टेस्ट केस उत्पन्न करके तेजी से विस्तार करने की क्षमता के साथ सरल ऑनलाइन डिबगिंग का भी समर्थन करता है।"
"टेस्टस्प्राइट का स्वचालन हमें बहुत सारे मैन्युअल काम को कम करने में मदद करता है। डेवलपर्स विकास प्रक्रिया में पहले ही बग्स को आसानी से पकड़ और हल कर सकते हैं।"
FAQ
हेडलेस CI रनर में CLI कैसे ऑथेंटिकेट होता है?
TESTSPRITE_API_KEY को एक सीक्रेट के रूप में सेट करें, फिर testsprite setup --from-env --yes --agent claude (या अपनी पसंद का एजेंट) चलाएँ। कोई इंटरैक्टिव प्रॉम्प्ट नहीं, कोई ब्राउज़र लॉगिन नहीं — यह बिल्कुल इसी के लिए बनाया गया है।
क्या यह खासतौर पर GitHub Actions के साथ काम करता है?
हाँ, और किसी भी CI के साथ जो शेल स्टेप चला सकता है — GitLab CI, CircleCI, Jenkins, Buildkite। यह npm से इंस्टॉल होने वाला एक Node.js CLI है; अगर आपका रनर यह कर सकता है, तो वह TestSprite चला सकता है।
पाइपलाइन असल में किस चीज़ पर गेट लगाती है?
आपके डिप्लॉय किए गए एनवायरनमेंट पर एक असली टेस्ट रन — Playwright के ज़रिए ब्राउज़र टेस्ट, डिपेंडेंसी मैनेजमेंट के साथ API टेस्ट — जिसकी रिपोर्ट एक स्थिर, दस्तावेज़ीकृत एग्ज़िट कोड के साथ वापस आती है। आपका मौजूदा "non-zero पर जॉब फेल करें" स्टेप बस काम कर जाता है।
क्या मैं लाइव होने से पहले पाइपलाइन की वायरिंग टेस्ट कर सकता हूँ?
हाँ — --dry-run टेस्ट डेटा के खिलाफ़ ऑफ़लाइन आपके टेस्ट लॉजिक को चलाकर देखता है, ताकि आप किसी असली एनवायरनमेंट पर पॉइंट करने से पहले पुष्टि कर सकें कि स्टेप सही से जुड़ा है।
जब CI किसी असली रिग्रेशन को पकड़ता है तो क्या होता है?
आपको उस रन से जुड़ा एक फेलियर बंडल मिलता है (फेल हुआ स्टेप, स्क्रीनशॉट, DOM स्नैपशॉट, रूट-कॉज़ परिकल्पना, फिक्स सिफ़ारिश) — इसे जॉब लॉग या किसी फॉलो-अप स्टेप से testsprite test failure get <testId> से पाएँ।