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

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

आवश्यक स्क्रिप्ट

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

package.json के अंदर, आपको test नाम की एक स्क्रिप्ट जोड़नी होगी, जो टेस्ट कैसे चलाया जाता है. यह ज़रूरी है, क्योंकि एनपीएम या इससे मिलते-जुलते यूआरएल का इस्तेमाल करते समय टूल, "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 को इसके एक चरण के तौर पर चलती है.

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

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

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

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

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

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

लुढ़कते हुए वापस आने जैसा

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

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

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

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

संसाधन

• नाइटली बिल्डिंग बनाने के क्या फ़ायदे हैं

देखें कि आपको कितना समझ आया है