कुछ टेस्ट प्लान चलने से पहले ही टूटे होते हैं।
एक मैलफ़ॉर्म्ड स्टेप या अनडिफ़ाइंड सेलेक्टर साफ़-साफ़ फेल नहीं होता — यह पता लगाने में एक पूरा रन बर्बाद हो जाता है। testsprite test lint <planFile> पहले टेस्ट प्लान की संरचना जाँचता है, ताकि आप समय या क्रेडिट खर्च करने से पहले ही समस्या पकड़ लें।
उसी CLI में बना-बनाया, जो आप पहले से चलाते हैं
मैलफ़ॉर्म्ड स्टेप पकड़ें
testsprite test lint <planFile> टेस्ट प्लान के हर एक्शन और एसर्शन स्टेप में स्ट्रक्चरल समस्याएँ जाँचता है — इससे पहले कि उनमें से कोई भी आपके लाइव एनवायरनमेंट के खिलाफ़ चले।
अस्पष्ट एसर्शन फ़्लैग करें
बिना साफ़ टारगेट वाला एसर्शन एक ऐसी समस्या है जिसे आप रन के बीच में खोजना नहीं चाहेंगे। Lint इसे तब पकड़ लेता है जब प्लान अभी सिर्फ़ एक JSON फ़ाइल है।
गायब सेलेक्टर ढूँढें
एक स्टेप जो ऐसे सेलेक्टर को रेफ़र करता है जो प्लान में कभी डिफ़ाइन ही नहीं हुआ, वह तुरंत फ़्लैग हो जाता है, बाद में एक उलझाने वाले फेलियर के रूप में सामने आने के बजाय।
किसी भी टेस्ट प्लान पर काम करता है
Lint किसी भी टेस्ट-प्लान JSON फ़ाइल पर चलता है — चाहे वह TestSprite से जनरेट हुई हो या हाथ से एडिट की गई हो — तो यह फ़िट बैठता है चाहे आपके प्लान असल में कैसे भी बनें।
$ testsprite test lint test-plan.json
Checking test-plan.json for structural problems...
✗ 2 issues found
- step 3: assertion is missing a clear target
- step 7: selector not defined in this plan
→ fix these before running the plan
$ testsprite test lint test-plan.json
Checking test-plan.json for structural problems...
✓ no structural problems found
ऐसे प्लान पर रन खर्च मत कीजिए जो कभी काम करने वाला ही नहीं था
मैलफ़ॉर्म्ड स्टेप या अनडिफ़ाइंड सेलेक्टर वाला टेस्ट प्लान इसलिए फेल नहीं होता क्योंकि आपका प्रोडक्ट टूटा है — यह इसलिए फेल होता है क्योंकि प्लान में ही एक स्ट्रक्चरल समस्या है। Linting इसे शुरुआत में ही पकड़ लेता है, इससे पहले कि यह आपको एक रन की क़ीमत चुकाए।
ऐसे टेस्ट प्लान के लिए बनाया गया जिन्हें हाथ से एडिट किया जाता है
किसी भी टेस्ट प्लान पर काम करता है
जनरेट हुआ हो या एडिट किया हुआ, फ़र्क़ नहीं पड़ता — test lint आपके प्रोजेक्ट की किसी भी टेस्ट-प्लान JSON फ़ाइल पर चलता है।
लूप में वापस फ़ीड होता है
टेस्ट प्लान जनरेट या एडिट करने वाला कोई एजेंट उसे test run को सौंपने से पहले test lint कॉल कर सकता है, समस्याओं को तब पकड़ते हुए जब उन्हें ठीक करना अभी सस्ता है।
मुफ़्त कम्युनिटी वर्ज़न
एक मुफ़्त कम्युनिटी वर्ज़न देता है, जिससे यह सबके लिए सुलभ बनता है।
रनिंग के साथ जोड़ी बनाता है
testsprite test lint को testsprite test run से ठीक पहले चलाएँ, ताकि किसी स्ट्रक्चरल समस्या को कभी असली रन जलाने का मौक़ा न मिले।
दुनिया भर के व्यवसायों द्वारा विश्वसनीय
"टेस्टस्प्राइट समृद्ध टेस्ट केस जनरेशन, स्पष्ट संरचना और पढ़ने में आसान कोड प्रदान करता है। यह नए टेस्ट केस उत्पन्न करके तेजी से विस्तार करने की क्षमता के साथ सरल ऑनलाइन डिबगिंग का भी समर्थन करता है।"
"टेस्टस्प्राइट का स्वचालन हमें बहुत सारे मैन्युअल काम को कम करने में मदद करता है। डेवलपर्स विकास प्रक्रिया में पहले ही बग्स को आसानी से पकड़ और हल कर सकते हैं।"
FAQ
testsprite test lint असल में क्या जाँचता है?
यह एक टेस्ट-प्लान JSON फ़ाइल की संरचना जाँचता है — मैलफ़ॉर्म्ड एक्शन या एसर्शन स्टेप, बिना साफ़ टारगेट वाले एसर्शन, और रेफ़र किए गए पर कभी डिफ़ाइन न हुए सेलेक्टर जैसी चीज़ें — इससे पहले कि प्लान आपके लाइव एनवायरनमेंट के खिलाफ़ चले।
यह सिर्फ़ टेस्ट प्लान चलाकर देखने से कैसे अलग है कि क्या होता है?
प्लान चलाने में यह पता लगाने में समय और क्रेडिट खर्च होते हैं कि प्लान ही टूटा हुआ था। Linting वही स्ट्रक्चरल समस्याएँ सिर्फ़ JSON फ़ाइल से ही ढूँढ लेता है, कुछ भी एक्ज़ीक्यूट होने से पहले।
क्या यह उन टेस्ट प्लान पर भी काम करता है जो मैंने हाथ से लिखे या एडिट किए, सिर्फ़ जनरेट किए हुओं पर नहीं?
हाँ — test lint किसी भी टेस्ट-प्लान JSON फ़ाइल पर चलता है, चाहे वह TestSprite से आई हो या सीधे एडिट की गई हो।
जब test lint कोई समस्या ढूँढे तो मैं क्या करूँ?
टेस्ट-प्लान JSON फ़ाइल में फ़्लैग किए गए स्टेप को ठीक करें और इसे फिर से लिंट करें। एक साफ़ पास का मतलब है कि प्लान रन पर खर्च करने से पहले स्ट्रक्चरली सही है।
क्या मुझे हर बार test lint चलाना चाहिए, उन प्लान पर भी जो मैंने पहले चलाए हैं?
इसे चलाना सस्ता है और यह हाथ से किए गए एडिट से आई समस्याओं को पकड़ता है, तो test run से पहले इसे चलाना एक उचित आदत है — ख़ासकर CI में।