टेस्ट कहां चलते हैं

अपने-आप होने वाले टेस्ट, आम तौर पर मैन्युअल तरीके से स्क्रिप्ट चलाकर या जांच वाले फ़्रेमवर्क के हेल्पर की मदद से किए जा सकते हैं. टेस्टिंग फ़्रेमवर्क को अक्सर टेस्ट रनर कहा जाता है. इसकी मदद से, जांच को ढूंढा और चलाया जा सकता है. हालांकि, हो सकता है कि आपको हमेशा अपनी स्क्रिप्ट को मैन्युअल रूप से न चलाना पड़े. टेस्ट करने के कई तरीके हैं जिनसे डेवलपमेंट की लाइफ़साइकल के दौरान, अलग-अलग समय पर सुझाव और भरोसा मिल सकता है.

पूर्वापेक्षा स्क्रिप्ट

वेब प्रोजेक्ट में आम तौर पर एक कॉन्फ़िगरेशन फ़ाइल होती है. यह उनकी package.json फ़ाइल होती है, जो npm, pnpm, बन या इसी तरह की किसी अन्य फ़ाइल के ज़रिए सेट अप की जाती है. इस कॉन्फ़िगरेशन फ़ाइल में, आपके प्रोजेक्ट की डिपेंडेंसी और अन्य जानकारी के साथ-साथ हेल्पर स्क्रिप्ट भी शामिल होती हैं. इन सहायक स्क्रिप्ट में, प्रोजेक्ट को बनाने, चलाने या उसकी जांच करने का तरीका शामिल हो सकता है.

package.json के अंदर, आपको test नाम की एक स्क्रिप्ट जोड़नी होगी, जो बताती है कि आपके टेस्ट कैसे किए जाते हैं. यह ज़रूरी है, क्योंकि npm या इससे मिलते-जुलते टूल का इस्तेमाल करते समय, "test" स्क्रिप्ट का खास मतलब होता है. यह स्क्रिप्ट सिर्फ़ एक ऐसी फ़ाइल के बारे में बता सकती है, जिसमें अपवाद होता है—जैसे कि node tests.js—लेकिन हमारा सुझाव है कि आप इसका इस्तेमाल किसी पहले से मालूम टेस्ट रनर को दिखाने के लिए करें.

अगर आप टेस्ट रनर के तौर पर Vitest का इस्तेमाल कर रहे हैं, तो आपकी package.json फ़ाइल कुछ इस तरह दिखेगी:

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

इस फ़ाइल के साथ npm test चलाने पर Vitest का डिफ़ॉल्ट सेट एक बार टेस्ट करता है. Vitest में, डिफ़ॉल्ट रूप से उन सभी फ़ाइलों को ढूंढना होता है जिनके आखिर में ".test.js" या मिलते-जुलते होते हैं और उन्हें चलाया जाता है. आपके चुने हुए टेस्ट रनर के हिसाब से, कमांड कुछ अलग हो सकता है.

हमने इस कोर्स के उदाहरणों के लिए, Vitest को इस्तेमाल करना चुना है. यह एक ऐसा टेस्ट फ़्रेमवर्क है जो लगातार लोकप्रिय हो रहा है. इस फ़ैसले के बारे में ज़्यादा जानने के लिए, टेस्ट रनर के तौर पर Vitest में जाएं. हालांकि, यह ध्यान रखना ज़रूरी है कि टेस्ट फ़्रेमवर्क और रनर (यहां तक कि सभी भाषाओं के लिए) एक समान भाषा में होते हैं.

मैन्युअल टेस्ट को शुरू करने की प्रक्रिया

कोड बेस पर काम करते समय, अपने-आप होने वाले टेस्ट को मैन्युअल तरीके से ट्रिगर करना (जैसे, पिछले उदाहरण में npm test का इस्तेमाल करना) किया जा सकता है. किसी सुविधा को डेवलप करते समय उसके लिए टेस्ट लिखने से, आपको यह जानने में मदद मिल सकती है कि उस सुविधा को कैसे काम करना चाहिए. इससे टेस्ट-ड्रिवन डेवलपमेंट (टीडीडी) के सिद्धांत के बारे में पता चलता है.

टेस्ट रनर के पास आम तौर पर एक छोटा सा निर्देश होता है, जिसे आप अपने कुछ या सभी टेस्ट चलाने के लिए शुरू कर सकते हैं. साथ ही, टेस्ट रनर मोड भी हो सकता है, जिसमें टेस्ट सेव करने के बाद फिर से टेस्ट शुरू कर दिया जाता है. नई सुविधा डेवलप करते समय, ये सभी विकल्प मददगार होते हैं. इन्हें इस तरह से डिज़ाइन किया गया है कि नई सुविधा, उसके टेस्ट या दोनों में से किसी एक को, तेज़ी से फ़ीडबैक के साथ लिखना आसान हो. उदाहरण के लिए, Vitest, डिफ़ॉल्ट रूप से वॉचर मोड में काम करता है: vitest कमांड, बदलावों पर नज़र रखेगा और उसे मिलने वाले किसी भी टेस्ट को फिर से चलाएगा. हमारा सुझाव है कि टेस्ट लिखते समय, इसे किसी दूसरी विंडो में खुला रखें, ताकि टेस्ट डेवलप करने के बाद, आपको उनके बारे में तेज़ी से सुझाव मिल सके.

कुछ रनर आपको अपने कोड में टेस्ट को only के तौर पर मार्क करने की सुविधा भी देते हैं. अगर आपके कोड में only के टेस्ट शामिल हैं, तो सिर्फ़ ये टेस्ट तब ट्रिगर होंगे, जब टेस्ट को चलाया जा रहा हो. इससे टेस्ट डेवलपमेंट को तेज़ी से और आसानी से हल किया जा सकेगा. भले ही, आपके सभी टेस्ट जल्दी पूरे हो जाएं, लेकिन only का इस्तेमाल करने से आपका ओवरहेड कम हो सकता है. साथ ही, जिस सुविधा या टेस्ट पर काम चल रहा है उससे अलग टेस्ट को चलाने में आने वाली रुकावटों को दूर किया जा सकता है.

छोटे प्रोजेक्ट, खास तौर पर सिर्फ़ एक डेवलपर वाले प्रोजेक्ट के लिए, हो सकता है कि आप अपने कोडबेस के पूरे टेस्ट सुइट को नियमित रूप से चलाने की आदत डालना चाहें. खास तौर पर, अगर आपके टेस्ट छोटे हैं और तेज़ी से पूरे होते हैं (आपके सभी टेस्ट के लिए, कुछ सेकंड से भी ज़्यादा नहीं), तो इससे आपको और आगे बढ़ने से पहले यह पक्का करने में मदद मिलती है कि सब कुछ ठीक से काम कर रहा है.

पहले से सबमिट करने या समीक्षा करने के दौरान टेस्ट करना

जब कोड को उसकी main ब्रांच में फिर से मर्ज करना होता है, तो कई प्रोजेक्ट यह पुष्टि करते हैं कि कोडबेस सही तरीके से काम कर रहा है. अगर आपने अभी टेस्ट नहीं किया है, लेकिन आपने पहले ओपन सोर्स प्रोजेक्ट में योगदान दिया होगा, तो आपने देखा होगा कि पुल के अनुरोध (पीआर) की प्रोसेस का एक हिस्सा यह पुष्टि करता है कि प्रोजेक्ट के सभी टेस्ट पास हो गए हैं. इसका मतलब है कि आपके नए योगदान से मौजूदा प्रोजेक्ट पर कोई बुरा असर नहीं पड़ा है.

अगर स्थानीय तौर पर टेस्ट चलाया जाता है, तो आपके प्रोजेक्ट की ऑनलाइन रिपॉज़िटरी (उदाहरण के लिए, GitHub या कोड होस्ट करने वाली कोई दूसरी सेवा) को यह पता नहीं चलेगा कि आपके टेस्ट पास हो रहे हैं. इसलिए, प्री-सबमिट टास्क के तौर पर टेस्ट चलाने से, योगदान देने वाले सभी लोगों को यह साफ़ हो जाता है कि सब कुछ ठीक से काम कर रहा है.

उदाहरण के लिए, GitHub इन्हें "स्थिति की जांच" के रूप में पेश करता है. इन्हें GitHub ऐक्शन की मदद से जोड़ा जा सकता है. GitHub ऐक्शन, बुनियादी तौर पर एक तरह का टेस्ट है: कार्रवाई को पास करने के लिए, हर चरण कामयाब होना चाहिए (गलत नहीं होना चाहिए या Error नहीं डालना चाहिए). किसी प्रोजेक्ट के लिए सभी पीआर पर कार्रवाइयां लागू की जा सकती हैं. साथ ही, प्रोजेक्ट के लिए यह ज़रूरी हो सकता है कि कोड का योगदान देने से पहले 'कार्रवाइयां' पास हो. GitHub की डिफ़ॉल्ट Node.js कार्रवाई, npm test को अपने एक चरण के तौर पर चलाती है.

जांच करने का यह तरीका यह पक्का करने की कोशिश करता है कि आपका कोडबेस हमेशा "हरा" रहे और उस कोड को स्वीकार न किया जाए जो अपने जांच को सही तरीके से नहीं चलाता है.

लगातार इंटिग्रेशन के हिस्से के तौर पर टेस्ट चलाना

ग्रीन पीआर को स्वीकार कर लेने के बाद, ज़्यादातर कोडबेस पिछली पीआर के बजाय, आपके प्रोजेक्ट की main ब्रांच के आधार पर फिर से टेस्ट करते हैं. ऐसा तुरंत या नियमित तौर पर हो सकता है (उदाहरण के लिए, हर घंटे या हर रात के लिए). इन नतीजों को अक्सर कंटिन्यूअस इंटिग्रेशन (सीआई) डैशबोर्ड के हिस्से के तौर पर दिखाया जाता है. इस डैशबोर्ड से प्रोजेक्ट की पूरी जानकारी मिलती है.

यह CI चरण ज़रूरी नहीं लग सकता है, खास तौर पर छोटे कोडबेस वाले प्रोजेक्ट के लिए. समीक्षा के दौरान टेस्ट पास हो जाते हैं, इसलिए बदलाव लागू होने पर उन्हें पास हो जाना चाहिए. हालांकि, यह ज़रूरी नहीं है! हरे रंग के नतीजे आने के बाद भी, आपके टेस्ट अचानक फ़ेल हो सकते हैं. ऐसा इन वजहों से हो सकता है:

• कई बदलावों को "एक बार में" स्वीकार किया गया. इसे कभी-कभी रेस कंडिशन भी कहा जाता है. इन बदलावों का असर एक-दूसरे पर हल्के-फुल्के, बिना पर वाले जांचे से होता है.
• आपके टेस्ट फिर से जनरेट नहीं किए जा सकते या उनमें "फ़्लैकी" कोड टेस्ट किया जाता है. कोड में कोई बदलाव किए बिना, दोनों ही पास हो सकते हैं और फ़ेल हो सकते हैं.
  • ऐसा तब हो सकता है, जब आप अपने कोड बेस के बाहर के सिस्टम पर निर्भर करते हैं. प्रॉक्सी के लिए, अगर Math.random() > 0.05 है, तो टेस्टिंग करने पर 5% बार यह फ़ेल हो जाएगा.
• कुछ टेस्ट हर पीआर पर चलाना बहुत महंगा या महंगा होता है, जैसे कि एंड-टू-एंड टेस्ट (अपने-आप होने वाले टेस्ट के टाइप में इसके बारे में ज़्यादा जानकारी) और वे समय-समय पर बिना सूचना दिए काम कर सकते हैं.

इनमें से किसी भी समस्या से निपटना नामुमकिन नहीं है, लेकिन आम तौर पर, टेस्टिंग और सॉफ़्टवेयर डेवलपमेंट का इस्तेमाल करके, कोई सटीक विज्ञान नहीं होता.

रोल बैक करने में अंतराल

जब टेस्ट को लगातार इंटिग्रेशन के तौर पर चलाया जाता है और यहां तक कि जब टेस्ट को स्टेटस की जांच के तौर पर चलाया जाता है, तब भी हो सकता है कि बिल्ड “लाल” स्थिति में आ जाए या किसी दूसरी स्थिति में हो. इसका मतलब है कि टेस्ट काम नहीं कर रहे हैं. जैसा कि पहले बताया गया है, ऐसा कई वजहों से हो सकता है. जैसे, टेस्ट सबमिट करने पर रेस कंडिशन या गड़बड़ी वाले टेस्ट.

छोटे प्रोजेक्ट के लिए, आपका इरादा इसे ही संकट समझने का हो सकता है! सब कुछ बंद करें, रोल बैक करें या आपत्तिजनक बदलाव को पहले जैसा करें, और पहले से मालूम अच्छी स्थिति में वापस आएं. यह एक मान्य तरीका हो सकता है, लेकिन यह याद रखना ज़रूरी है कि जांच (और सामान्य तौर पर सॉफ़्टवेयर!) का मतलब सिर्फ़ खत्म होना है, न कि उसका मकसद. शायद आपका लक्ष्य सॉफ़्टवेयर लिखना है, न कि सभी टेस्ट पास करना. इसके बजाय, गड़बड़ी वाले बदलाव को फ़ॉलो अप करके, फ़ॉरवर्ड करें को रोल आउट किया जा सकता है. इसके लिए, ऐसा दूसरा बदलाव करें जो फ़ेल हो चुके टेस्ट को ठीक करता हो.

वहीं दूसरी ओर, आपने ऐसे बड़े प्रोजेक्ट देखे होंगे या उन पर काम किया होगा जो हमेशा के लिए बने हुए हैं. इससे भी बुरा बात यह है कि बड़े प्रोजेक्ट में ऐसा टेस्ट होता है जो ठीक से काम नहीं करता. इससे अक्सर डेवलपर को अलार्म थकान की समस्या पैदा हो जाती है. इसे अक्सर नेताओं के लिए एक अस्तित्व की समस्या का हल निकालना पड़ता है: इन जांचों को बंद भी किया जा सकता है, क्योंकि इन्हें "विकास के रास्ते में रुकावट डालते हुए " के तौर पर देखा जाता है.

इसे तुरंत ठीक करने का कोई तरीका नहीं है. हालांकि, टेस्ट लिखने के टेस्ट में ज़्यादा आत्मविश्वास पैदा करने (अपस्किलिंग) और टेस्ट के दायरे को कम करने (आसान बनाने) में मदद मिल सकती है, ताकि गड़बड़ियों की ज़्यादा आसानी से पहचान की जा सके. कॉम्पोनेंट टेस्ट या इंटिग्रेशन टेस्ट की बढ़ी हुई संख्या (अपने-आप होने वाले टेस्ट के टाइप के बारे में ज़्यादा जानकारी), एक ऐसे एंड-टू-एंड टेस्ट से ज़्यादा भरोसेमंद होती है जिसे मैनेज करना मुश्किल होता है और जिसे एक साथ करने की कोशिश करना भी मुश्किल होता है.

रिसॉर्स

• एक रात में इमारतें बनाने के क्या फ़ायदे हैं

जांचें कि आपको कितना समझ आया