एक फेल हुआ CI रन आपका पहला संकेत नहीं होना चाहिए कि कुछ ग़लत कॉन्फ़िगर्ड है।
TestSprite को CI में जोड़ने से पहले testsprite doctor चलाएँ। यह जाँचता है कि आपकी API की, नेटवर्क एक्सेस, और CLI वर्ज़न सभी सही तरीके से कॉन्फ़िगर हैं — ताकि कोई बेवकूफ़ाना सेटअप समस्या असली टेस्ट फेलियर का रूप न ले ले।
उसी CLI में बना-बनाया, जो आप पहले से चलाते हैं
अपनी API की वेरिफ़ाई करें
testsprite doctor कन्फ़र्म करता है कि आपकी TESTSPRITE_API_KEY सेट और वैध है, इससे पहले कि कोई CI जॉब ऑथेंटिकेशन एरर पर अपना पहला रन जला दे।
नेटवर्क और प्रॉक्सी एक्सेस जाँचें
कॉर्पोरेट प्रॉक्सी और लॉक्ड-डाउन CI रनर चुपचाप आउटबाउंड रिक्वेस्ट ब्लॉक कर सकते हैं। Doctor कन्फ़र्म करता है कि CLI असल में TestSprite तक पहुँच सकता है, इससे पहले कि आपको यह पाइपलाइन के बीच में पता चले।
अपना CLI वर्ज़न कन्फ़र्म करें
इंस्टॉल्ड और आपकी पाइपलाइन की उम्मीद के बीच वर्ज़न मिसमैच ऐसे तरीकों से फेल हो सकता है जो प्रोडक्ट बग जैसा दिखे। Doctor ऐसा होने से पहले इसे फ़्लैग करता है।
इसे कहीं भी चलाएँ
चाहे आप लोकल पर सेटअप कर रहे हों, कोई नई CI जॉब जोड़ रहे हों, या यह डीबग कर रहे हों कि टीममेट की पाइपलाइन ऑथेंटिकेट क्यों नहीं हो रही, चेक वही रहता है।
$ testsprite doctor Checking environment... ✓ API key found and valid ✓ Network access to TestSprite confirmed ✓ CLI version up to date → environment looks good, ready to run tests $ testsprite doctor Checking environment... ✗ TESTSPRITE_API_KEY not set ✗ Network request blocked — check proxy configuration → fix these before running testsprite test run
CI को आपके लिए आपका कॉन्फ़िग डीबग न करने दें
एक पाइपलाइन जो आपके टेस्ट तक पहुँचने से पहले ही फेल हो जाती है, वह कुछ भी टेस्ट नहीं कर रही — वह बस ज़ोर से फेल हो रही है। पहले testsprite doctor चलाने से "CI अभी फेल क्यों हुआ" का जवाब दो सेकंड में मिल जाता है।
TestSprite को CI में जोड़ने के लिए बनाया गया
CI जोड़ने से पहले इसे चलाएँ
testsprite doctor को अपनी पाइपलाइन के पहले स्टेप के रूप में जोड़ें — इंस्टॉल के ठीक बाद, testsprite setup और किसी भी असली टेस्ट रन से पहले।
testsprite setup के साथ जोड़ी बनाता है
क्रेडेंशियल्स को नॉन-इंटरैक्टिव तरीके से कॉन्फ़िगर करने के लिए testsprite setup --from-env --yes --agent <name> इस्तेमाल करें, फिर यह कन्फ़र्म करने के लिए doctor चलाएँ कि वे असल में काम करते हैं।
मुफ़्त और ओपन सोर्स
npm install -g @testsprite/testsprite-cli आपको CLI देता है। यह Apache-2.0 लाइसेंस्ड है, तो पहला चेक करने में कुछ भी नहीं रोकता।
मशीन-रीडेबल आउटपुट
नतीजे ऐसे फ़ॉर्मैट में पाने के लिए --output json पास करें जिसे आपकी पाइपलाइन पार्स करके अपने आप एक्ट कर सके।
दुनिया भर के व्यवसायों द्वारा विश्वसनीय
"टेस्टस्प्राइट समृद्ध टेस्ट केस जनरेशन, स्पष्ट संरचना और पढ़ने में आसान कोड प्रदान करता है। यह नए टेस्ट केस उत्पन्न करके तेजी से विस्तार करने की क्षमता के साथ सरल ऑनलाइन डिबगिंग का भी समर्थन करता है।"
"टेस्टस्प्राइट का स्वचालन हमें बहुत सारे मैन्युअल काम को कम करने में मदद करता है। डेवलपर्स विकास प्रक्रिया में पहले ही बग्स को आसानी से पकड़ और हल कर सकते हैं।"
FAQ
testsprite doctor असल में क्या जाँचता है?
यह जाँचता है कि आपकी API की सेट और वैध है, कि CLI आपके नेटवर्क पर TestSprite तक पहुँच सकता है — प्रॉक्सी के ज़रिए भी — और कि आपका इंस्टॉल्ड CLI वर्ज़न अप टू डेट है।
मुझे इसे कब चलाना चाहिए?
CLI इंस्टॉल करने के तुरंत बाद, और फिर से किसी भी नई CI पाइपलाइन के पहले स्टेप के रूप में — testsprite setup या किसी असली टेस्ट रन से पहले, ताकि कॉन्फ़िग समस्या पाइपलाइन के बीच में नहीं, तेज़ी से फेल हो जाए।
यह सिर्फ़ टेस्ट चलाकर देखने से कैसे अलग है कि क्या टूटता है?
missing API key या ब्लॉक्ड नेटवर्क रिक्वेस्ट की वजह से फेल हुआ टेस्ट रन तब तक असली प्रोडक्ट फेलियर जैसा ही दिखता है जब तक आप गहराई में न जाएँ। Doctor "आपका सेटअप टूटा है" को "आपका प्रोडक्ट टूटा है" से अलग करता है, इससे पहले कि आप ग़लत वाले पर एक रन बर्बाद करें।
क्या यह CI में काम करता है, या सिर्फ़ लोकल पर?
दोनों में — यह दोनों तरफ़ एक ही कमांड है। सेटअप करते वक़्त इसे लोकल पर चलाएँ, फिर एक CI स्टेप के रूप में फिर से चलाएँ, ताकि पाइपलाइन एनवायरनमेंट में प्रॉक्सी या क्रेडेंशियल की समस्या छूट न जाए।
अगर यह कोई समस्या फ़्लैग करे तो?
यह आपको बताता है कि क्या ग़लत है — missing TESTSPRITE_API_KEY, ब्लॉक्ड नेटवर्क पाथ, या पुराना CLI वर्ज़न — ताकि आप उस एक चीज़ को ठीक कर सकें, बजाय ऐसे टेस्ट रन को डीबग करने के जिसे शुरू होने का मौक़ा ही नहीं मिला।