सीएलआई को आपके फ़ायरवॉल पर रुकना नहीं है।
उसी सीएलआई में बना-बनाया, जो आप पहले से चला रहे हैं
एक बार कॉन्फ़िगर करें, हर जगह चले
प्रॉक्सी को अपनी बाक़ी सीएलआई कॉन्फ़िगरेशन के साथ ही सेट अप करें, और हर कमांड — टेस्ट जनरेशन, रीरन, आर्टिफ़ैक्ट पुल — अपने आप उसी से होकर रूट होता है।
कोई ख़ास नेटवर्क अपवाद नहीं
CLI उसी कॉर्पोरेट प्रॉक्सी के ज़रिए TestSprite के क्लाउड सैंडबॉक्स तक पहुँचती है जो आपके बाक़ी डेवलपर टूल्स पहले से इस्तेमाल करते हैं, तो नेटवर्क या सिक्योरिटी टीम को मंज़ूर करने के लिए कुछ नया नहीं है।
CI में भी काम करती है, सिर्फ़ आपके लैपटॉप पर नहीं
सेटअप testsprite setup --from-env --yes --agent <name> से नॉन-इंटरैक्टिव तरीके से चल सकता है, तो प्रॉक्सी कॉन्फ़िगरेशन उसी नेटवर्क पॉलिसी के पीछे चल रहे CI पाइपलाइनों में साफ़-सुथरे तरीके से पहुँच जाता है।
क्रेडेंशियल अलग से मैनेज होते रहते हैं
प्रॉक्सी कॉन्फ़िगरेशन और project credential से स्टोर किए गए प्रोजेक्ट क्रेडेंशियल एक-दूसरे से स्वतंत्र हैं, तो नेटवर्क बदलने का मतलब API की फिर से एंट्री करना नहीं है।
नेटवर्क पॉलिसी को यह तय न करने दें कि आप क्या ऑटोमेट कर सकते हैं
लॉक्ड-डाउन नेटवर्क पॉलिसी वाली कंपनियों में डेवलपर्स अक्सर क्लाउड-कनेक्टेड सीएलआई टूल्स का इस्तेमाल बिल्कुल नहीं कर पाते — हर आउटबाउंड रिक्वेस्ट बिल्डिंग छोड़ने से पहले ही ब्लॉक हो जाती है। प्रॉक्सी सपोर्ट का मतलब है कि TestSprite CLI उस पॉलिसी के अंदर रहकर काम करती है, उसमें अपवाद माँगने के बजाय।
कॉर्पोरेट फ़ायरवॉल के पीछे काम करने वाली टीमों के लिए बनाया गया
स्टैंडर्ड कॉर्पोरेट प्रॉक्सी के साथ काम करती है
CLI के अपने ही सेटअप फ़्लो से कॉन्फ़िगर होती है, तो IT को ख़ास तौर पर TestSprite के लिए इंटरनेट का सीधा रास्ता खोलने की ज़रूरत नहीं।
मौजूदा CI पाइपलाइनों में फ़िट बैठती है
testsprite setup --from-env --yes --agent <name> से नॉन-इंटरैक्टिव सेटअप प्रॉक्सी कॉन्फ़िगरेशन को GitHub Actions, GitLab CI, या उसी पॉलिसी के पीछे बैठे किसी भी रनर तक पहुँचा देता है।
कोई अलग एंटरप्राइज़ बिल्ड नहीं
प्रॉक्सी सपोर्ट उसी सीएलआई में मौजूद है जिसे आपने पहले ही npm install -g @testsprite/testsprite-cli से इंस्टॉल किया है — इसके लिए अलग से कुछ माँगने या लाइसेंस लेने की ज़रूरत नहीं।
क्रेडेंशियल मैनेजमेंट के साथ जोड़ी बनाती है
CLI TestSprite के क्लाउड सैंडबॉक्स तक कैसे पहुँचती है इससे स्वतंत्र, हर प्रोजेक्ट के लिए स्टोर किए क्रेडेंशियल मैनेज करने के लिए project credential इस्तेमाल करें।
दुनिया भर के व्यवसायों द्वारा विश्वसनीय
"टेस्टस्प्राइट समृद्ध टेस्ट केस जनरेशन, स्पष्ट संरचना और पढ़ने में आसान कोड प्रदान करता है। यह नए टेस्ट केस उत्पन्न करके तेजी से विस्तार करने की क्षमता के साथ सरल ऑनलाइन डिबगिंग का भी समर्थन करता है।"
"टेस्टस्प्राइट का स्वचालन हमें बहुत सारे मैन्युअल काम को कम करने में मदद करता है। डेवलपर्स विकास प्रक्रिया में पहले ही बग्स को आसानी से पकड़ और हल कर सकते हैं।"
FAQ
क्या TestSprite CLI कॉर्पोरेट HTTP/HTTPS प्रॉक्सी के पीछे काम करती है?
हाँ — प्रॉक्सी सपोर्ट CLI रिलीज़ v0.3.0 में जोड़ा गया था। CLI को TestSprite के क्लाउड सैंडबॉक्स तक सीधे पहुँचने के बजाय कॉर्पोरेट प्रॉक्सी के ज़रिए अपना ट्रैफ़िक रूट करने के लिए कॉन्फ़िगर किया जा सकता है।
अगर मैं किसी लॉक्ड-डाउन नेटवर्क पर नहीं हूँ, तो यह क्यों मायने रखता है?
आपके लिए यह कुछ नहीं बदलता — प्रॉक्सी कॉन्फ़िगरेशन वैकल्पिक है। यह उन कंपनियों के डेवलपर्स के लिए मायने रखता है जहाँ हर आउटबाउंड ट्रैफ़िक को इंटरनेट तक पहुँचने से पहले ही एक अप्रूव्ड प्रॉक्सी से गुज़रना पड़ता है।
क्या प्रॉक्सी सपोर्ट यह बदल देता है कि टेस्ट असल में कैसे चलते हैं?
नहीं। फ्रंटएंड टेस्ट अब भी एक ब्राउज़र के ज़रिए एक लाइव URL के खिलाफ़ चलते हैं, और बैकएंड टेस्ट अब भी एक बेस URL के खिलाफ़ चलते हैं, दोनों TestSprite के क्लाउड सैंडबॉक्स में Auto-Heal के साथ (भंगुर सेलेक्टर के लिए) चलाए जाते हैं। प्रॉक्सी सिर्फ़ यह बदलती है कि CLI उस सैंडबॉक्स तक कैसे पहुँचती है।
ऐसे नेटवर्क पर मैं CLI कैसे सेट अप करूँ?
वैसे ही जैसे आप इसे कहीं और सेट अप करते — testsprite setup से इंटरैक्टिव रूप से, या testsprite setup --from-env --yes --agent <name> से नॉन-इंटरैक्टिव रूप से, जो आपकी API की TESTSPRITE_API_KEY एनवायरनमेंट वेरिएबल से पढ़ता है।
क्या यह असर डालता है कि मेरे प्रोजेक्ट क्रेडेंशियल कैसे स्टोर होते हैं?
नहीं — प्रॉक्सी कॉन्फ़िगरेशन और project credential से क्रेडेंशियल स्टोरेज अलग-अलग हैंडल होते हैं, तो CLI नेटवर्क तक कैसे पहुँचती है इससे यह नहीं बदलता कि यह आपके प्रोजेक्ट के क्रेडेंशियल कैसे मैनेज करती है।
आपकी नेटवर्क पॉलिसी को आपके टेस्ट ऑटोमेशन को नहीं रोकना चाहिए।
CLI इंस्टॉल करें, इसे अपने कॉर्पोरेट प्रॉक्सी पर पॉइंट करें, और वही टेस्ट ऑटोमेशन चलाएँ जिस पर आपकी टीम पहले से भरोसा करती है — सिक्योरिटी से अपवाद माँगे बिना।