टेस्टिंग एनवायरमेंट

जैसा कि टेस्टिंग क्या है में बताया गया है, JavaScript में जांच बुनियादी तौर पर सिर्फ़ एक कोड होता है, जिसके लिए हम पुष्टि करते हैं कि वह ट्रिगर हो गया है. इसका मतलब है कि टेस्ट, Error का इस्तेमाल किए बिना चलता है. हालांकि, इस परिभाषा को ज़्यादा आसान बनाने का एक तरीका यह है कि इसमें इस बात पर ध्यान नहीं दिया जाता कि हम कोड को कहां चलाते हैं, यानी कि वह टेस्टिंग एनवायरमेंट है.

आम तौर पर, टेस्टिंग एनवायरमेंट को दो कॉम्पोनेंट के तौर पर देखा जा सकता है: टेस्ट के लिए इस्तेमाल किए जाने वाले रनटाइम एनवायरमेंट (जैसे कि नोड या ब्राउज़र) के साथ-साथ, आपके लिए उपलब्ध एपीआई.

रनटाइम एनवायरमेंट

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

ऐसे में, अगर आम तौर पर इस्तेमाल किए जाने वाले इन रनटाइम की कोशिश की जाती है, तो वे काम नहीं करेंगे. उदाहरण के लिए, रिऐक्ट एलिमेंट को रेंडर करना, ताकि उनकी जांच की जा सके, क्योंकि कोई document या window ऑब्जेक्ट उपलब्ध नहीं है.

वहीं दूसरी ओर, अगर टेस्ट किसी ब्राउज़र में किए जाते हैं, तो हो सकता है कि इन रनटाइम से पहले से मौजूद एपीआई, पॉलीफ़िल किए बिना या कुछ और काम किए बिना उपलब्ध न हों. सामान्य पॉचा, फ़ाइलों को पढ़ना और लिखना होता है: ब्राउज़र में import { fs } from 'node:'fs'; करना और टेस्ट के तौर पर किसी फ़ाइल को इस तरह से पढ़ना मुमकिन नहीं है.

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

एल्गोरिदम या कारोबार के लॉजिक की जांच करें

आपके कुछ कोड को ऑपरेट करने के लिए, नोड या ब्राउज़र इंपोर्ट की ज़रूरत नहीं पड़ेगी. साथ ही, टेस्ट भी नहीं किया जा सकेगा. हम इस कोर्स में आगे इसी बारे में बात करेंगे. हालांकि, अपने कोडबेस को इस तरह से स्ट्रक्चर करना कि उसका सटीक "कारोबारी लॉजिक", रेंडरिंग से अलग हो या नोड वाले कोड से टेस्ट करना आसान हो सकता है.

उदाहरण के लिए, आपके पास नोड फ़ंक्शन हो सकता है, जो डिस्क में मौजूद फ़ाइल को पढ़ता और लिखता है. साथ ही, इस प्रोसेस में फ़ाइल में बदलाव करता है. डिस्क से पढ़ने और लिखने वाले फ़ंक्शन स्वीकार करने के लिए, अपने फ़ंक्शन को फिर से रीफ़ैक्टर करके, आपने इसे कहीं भी टेस्ट करने लायक बना दिया है.

इस मामले में, सर्वर साइड रनटाइम या ब्राउज़र में, इस कोड की जांच करने के लिए किसी भी एनवायरमेंट का इस्तेमाल किया जा सकता है. जांच में, ऐसे हेल्पर जोड़े जा सकते हैं जो मेमोरी में वर्चुअल फ़ाइल सेव करते हैं या प्लेसहोल्डर का डेटा दिखाते हैं. इस तरह के हेल्पर को टेस्ट में शामिल करना सही है, क्योंकि यह जांच करना ज़रूरी नहीं है कि fs.writeFileSync काम करता है या नहीं. अपने कोड पर ध्यान दें और बताएं कि वह कोड यूनीक या खतरनाक क्यों है.

ब्राउज़र एपीआई को एम्युलेट करें

Vitest जैसे कई टेस्टिंग फ़्रेमवर्क में आपको ब्राउज़र के एपीआई एनवायरमेंट को एम्युलेट करने का विकल्प मिलता है. ऐसा, ब्राउज़र को चलाए बिना किया जाता है. Vitest अंदरूनी तौर पर JSDOM लाइब्रेरी का इस्तेमाल करता है. यह उन आसान कॉम्पोनेंट की जांच के लिए एक अच्छा विकल्प हो सकता है जहां ब्राउज़र का इस्तेमाल करने की ज़्यादा ज़रूरत होती है.

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

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

ब्राउज़र को एम्युलेट करना एक मान्य प्रक्रिया है—JSDOM को 2014 में रिलीज़ किया गया था. हालांकि, यह असली ब्राउज़र का इस्तेमाल करने से हमेशा अलग होता है. ये अंतर साफ़-साफ़ दिख सकते हैं: उदाहरण के लिए, JSDOM में लेआउट इंजन शामिल नहीं है. इसलिए, एलिमेंट के साइज़ की जांच करने या स्वाइप जैसे किसी मुश्किल जेस्चर की जांच करने का कोई तरीका नहीं है. ये अंतर मामूली भी हो सकते हैं और इनके बारे में जानकारी भी नहीं हो सकती. इसलिए, JSDOM पर आधारित टेस्ट को कम से कम रखें. इससे आपको ऐसे जोखिम को 'टाइमबॉक्स' करने का विकल्प मिलता है जो किसी भी व्यवहार से असली चीज़ों से अलग हो जाता है.

असली ब्राउज़र को कंट्रोल करें

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

टेस्ट के तौर पर किसी ब्राउज़र को कंट्रोल करने का मतलब है कि यह बिलकुल उसी तरह खुलेगा जैसे किसी उपयोगकर्ता के लिए खुलता है. इससे यूआरएल, कस्टम एचटीएमएल, और JS या आपकी जांच करने के लिए ज़रूरी चीज़ों को लोड करके टेस्ट को कंट्रोल किया जा सकता है. इसके बाद, उपयोगकर्ता की तरह काम करने के लिए कोड लिखा जा सकता है. जैसे, माउस को कंट्रोल करना या इनपुट बॉक्स में इनपुट टाइप करना.

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

पहले से मौजूद टेस्टिंग लाइब्रेरी (इसमें Vitest और Jest भी शामिल हैं) में अक्सर ब्राउज़र मोड होता है, लेकिन उनका ऑरिजिन Node.js से होता है. इसलिए, उनके ब्राउज़र मोड अक्सर "बोल्ड" किए जाते हैं और उनमें काम की सुविधाएं मौजूद नहीं होती हैं. उदाहरण के लिए, Vitest ब्राउज़र में मॉक मॉड्यूल को इंपोर्ट नहीं कर सकता. यह एक बहुत ही आसान तरीका है, जिसे हम अगले पेज पर दिए गए उदाहरण में इस्तेमाल करते हैं.

व्यावहारिक

जैसे-जैसे आपके टेस्ट जटिल होते जाते हैं, वैसे-वैसे असली ब्राउज़र का इस्तेमाल करना उतना ही ज़रूरी होता जाता है.

• ऐसे टेस्ट के लिए जो डीओएम की ओर से कोई सुविधा नहीं देते या कम से कम सुविधाओं का इस्तेमाल करते हैं, उनके लिए एनवायरमेंट मौजूद होने से कोई फ़र्क़ नहीं पड़ता. वे Node.js और इससे मिलते-जुलते रनटाइम, जैसे कि fetch या EventTarget में उपलब्ध सुविधाओं का भी इस्तेमाल करते हैं.
• छोटे कॉम्पोनेंट की जांच के लिए, JSDOM सही हो सकता है.
• बड़े टेस्ट—उदाहरण के लिए, एंड-टू-एंड टेस्ट जो उपयोगकर्ता के लॉग इन करने और मुख्य कार्रवाई को सिम्युलेट कर सकते हैं—यह असली ब्राउज़र में पूरी तरह से चलाने जैसा होता है.

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

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