अलग-अलग तरह के जांचों को दिए गए नामों की, सभी कोडबेस में एक जैसी थीम होती है, लेकिन उनकी सटीक परिभाषाएं नहीं होती हैं. इस कोर्स में हर तरह के टेस्ट का मतलब बताने वाले कुछ दिशा-निर्देश दिए गए हैं. हालांकि, दूसरे रिसॉर्स की अलग परिभाषाएं दे सकते हैं.
पिछले पेजों में, यूनिट टेस्ट और कॉम्पोनेंट, दोनों के उदाहरण दिए गए हैं (हमारे उदाहरण में, प्रतिक्रिया देने वाले कॉम्पोनेंट के बारे में बताया गया है). हम इन दोनों को अपने टेस्टिंग पिरामिड (या किसी दूसरे आकार!) पर रख सकते हैं, क्योंकि इनकी जटिलता कम है और ये तेज़ी से चलते हैं, लेकिन हो सकता है कि ज़्यादा मुश्किल इंटिग्रेशन टेस्ट जितना काम कर सकें.
सामान्य टेस्ट के टाइप
यूनिट टेस्ट
यूनिट टेस्ट का दायरा सबसे छोटा होता है. आम तौर पर उनका इस्तेमाल, कोड के छोटे-छोटे हिस्सों या पूरी तरह स्टेटलेस कोड की जांच करने के लिए किया जाता है. ये टेस्ट करीब-करीब गणित के तरीके से किए जाते हैं: अगर मैं आपका कोड X, Y, और Z के साथ दिखता हूं, तो उनका आउटपुट A, B, और C होना चाहिए.
यूनिट टेस्ट वाले कोड में आम तौर पर कोई बाहरी निर्भरता की ज़रूरत नहीं होगी. उदाहरण के लिए, किसी नेटवर्क से फ़ेच करना या किसी दूसरे फ़ंक्शन या लाइब्रेरी का इस्तेमाल करके, उसे फ़ेच करना. यह आपके कोड का ट्री नोड होता है, जिसे "काट" करके खुद ही टेस्ट किया जा सकता है.
यूनिट टेस्ट में तेज़ी से डेटा लिखा और चलता है. हालांकि, हमेशा ऐसा हो सकता है कि कोड की छोटी यूनिट की जांच करने से काम की जानकारी न मिले. अक्सर, दूसरे कोड के साथ किसी कोड यूनिट का इंटरैक्शन कम होने का मतलब है कि जोखिम को कम करने के लिए, बड़े लेवल पर टेस्ट करना बेहतर है.
कॉम्पोनेंट की जांच
वेब डेवलपर के लिए "कॉम्पोनेंट" नाम ओवरलोड हो गया है. इसका मतलब अक्सर, उपयोगकर्ता को दिखने वाला कॉम्पोनेंट होता है, जैसे कि प्रतिक्रिया देने वाला कॉम्पोनेंट या वेब कॉम्पोनेंट. इसकी ज़्यादा सामान्य परिभाषा, काम का वह हिस्सा है जिसकी जांच की जा सकती है. उदाहरण के लिए, बाहरी डिपेंडेंसी वाली क्लास. असरदार तरीके से टेस्ट किए जाने के लिए, इस कॉम्पोनेंट की डिपेंडेंसी को मॉक आउट करना होगा या इसे स्किप करना होगा.
आधुनिक वेब डेवलपमेंट के तरीके, किसी कॉम्पोनेंट के सिद्धांत पर आधारित होते हैं. इसलिए, कॉम्पोनेंट की जांच करना, टेस्टिंग के बारे में सोचने का एक व्यावहारिक तरीका होता है. उदाहरण के लिए, आप यह तय कर सकते हैं कि हर कॉम्पोनेंट की जांच की ज़रूरत हो. कॉम्पोनेंट की जांच करना भी आसान होता है. अगर कोई डेवलपर या छोटी टीम किसी कॉम्पोनेंट पर मालिकाना हक का दावा करती है, तो उस कॉम्पोनेंट की जांच करना भी आसान होता है. हालांकि, पेचीदा डिपेंडेंसी को नज़रअंदाज़ करना मुश्किल हो सकता है.
इंटिग्रेशन की जांच
ये कॉम्पोनेंट, मॉड्यूल, सबसिस्टम या आपके कोड के काम के अन्य हिस्सों के छोटे ग्रुप की एक साथ जांच करते हैं, ताकि यह पक्का किया जा सके कि वे सही तरीके से काम कर रहे हैं. यह एक बहुत ही अस्पष्ट परिभाषा है. वेब डेवलपर के लिए, मान लें कि जिस कोड की जांच की जा रही है वह आपकी साइट का असली और प्रोडक्शन बिल्ड (या उसके आस-पास भी) नहीं है. हालांकि, वह आपके सिस्टम के कई मिलते-जुलते कॉम्पोनेंट को जोड़ता है.
इसमें "असल" डिपेंडेंसी भी शामिल हो सकती है, जैसे कि सिर्फ़ मॉक के बजाय टेस्ट मोड में बाहरी डेटाबेस. उदाहरण के लिए, यह कहने के बजाय कि query() हमेशा एक ही दो एंट्री दिखाएगा, आपका इंटिग्रेशन टेस्ट इस बात की पुष्टि कर सकता है कि टेस्ट डेटाबेस में कुछ है. डेटा अपने आप में कम महत्वपूर्ण होता है, लेकिन
अब आप इस बात की जांच कर रहे हैं कि डेटाबेस से कनेक्ट किया जा सकता है और उससे सफलतापूर्वक क्वेरी की जा सकती है.
अलग-अलग तरह के कॉम्पोनेंट से जुड़ी एक कार्रवाई की वजह से कई ऐसे असर हो सकते हैं जिनका आकलन किया जा सकता है. ऐसे में अलग-अलग तरह के संकेतों का इस्तेमाल करके आसान इंटिग्रेशन टेस्ट किए जा सकते हैं.
इस वजह से, इंटिग्रेशन की जांच से यह पता चल सकता है कि आपका कॉम्प्लेक्स सिस्टम सही तरीके से चलेगा या नहीं. हालांकि, उन्हें लिखना और मैनेज करना मुश्किल हो सकता है.
साथ ही, इनसे बेवजह की जटिलता आ सकती है. उदाहरण के लिए, इंटिग्रेशन टेस्ट के लिए FakeUserService लिखने पर, इसके और RealUserService, दोनों के लिए UserService लागू करना ज़रूरी हो जाता है.
धुएं की जांच
ये ऐसे टेस्ट हैं जो बहुत जल्दी पूरे होने चाहिए. इनसे यह भी पता चलता है कि आपका कोडबेस सही स्थिति में है या नहीं. व्यावहारिक तौर पर, इसका मतलब है कि कोड पर ऐसे आसान टेस्ट करना जिससे आपके अनुभव पर अलग-अलग तरह के असर पड़ सकते हैं.
उदाहरण के लिए, किसी बड़े साइन इन किए हुए वेब ऐप्लिकेशन में, इससे यह पक्का हो सकता है कि लॉगिन और पुष्टि करने वाला सिस्टम काम कर रहा है, क्योंकि इसके बिना ऐप्लिकेशन काम का नहीं है और इसके अलावा टेस्टिंग करना काम का नहीं है.
धुएं की जांच करने की सुविधा, बड़े कोड बेस में आपके Package.json की test
स्क्रिप्ट के तहत सही साबित हो सकती है. मैन्युअल तौर पर की जाने वाली जांच भी धुएं के एक तरह के टेस्ट की तरह काम कर सकती है.
रिग्रेशन टेस्ट
रिग्रेशन टेस्टिंग एक तरह का स्मोक टेस्ट है, जो यह पक्का करता है कि मौजूदा सुविधाएं काम करती रहें या किसी नई सुविधा के रिलीज़ होने या अन्य फ़ीचर डेवलप होने के बाद, पुरानी गड़बड़ियां फिर से दिखाई न दें.
यह, टेस्ट-ड्रिवन डेवलपमेंट (टीडीडी) के सिद्धांत से जुड़ा होता है. खास तौर पर बग ट्रिगर करने के लिए लिखे गए टेस्ट केस और बाद में उनका इस्तेमाल करके यह पक्का किया जाता है कि बग को ठीक कर दिया गया है. इसे रिग्रेशन टेस्ट केस के तौर पर गिना जाता है, क्योंकि उनके मौजूद होने से उस बग को वापस आने से रोका जाना चाहिए.
हालांकि, रिग्रेशन की जांच करने की सुविधा, किसी बेहतरीन समाधान के बिना एक समस्या हो सकती है. इस शब्द का इस्तेमाल अक्सर कारोबार की ज़रूरतों के लिए किया जाता है: जैसे-जैसे सुविधाएं बेहतर होती जाती हैं, वैसे-वैसे ज़रूरी होता है कि पुरानी सुविधाएं न टूटें. अच्छी तरह से जांचे गए कोडबेस के ज़रिए इसे बनाए रखा जा सकता है, लेकिन असली कोडबेस हमेशा उस आदर्श को पूरा नहीं करते हैं. आने वाले समय के सेक्शन में, इस बारे में ज़्यादा जानकारी दी जाएगी.
विज़ुअल टेस्ट
विज़ुअल टेस्ट में किसी वेबसाइट की स्थिति के बारे में बताने वाले स्क्रीनशॉट या वीडियो लिए जाते हैं, ताकि मौजूदा टेस्ट के मुकाबले वेबसाइट की अच्छी स्थिति (जैसे कि पिछला स्क्रीनशॉट) की जांच की जा सके. अपनी तरह से, इसके लिए ज़रूरी है कि एक असली ब्राउज़र चलाया जाए, ताकि वह एचटीएमएल, सीएसएस, और वेबसाइट के दूसरे हिस्सों को रेंडर कर सके.
आपके पूरे कोडबेस को चलाने वाले एंड-टू-एंड टेस्ट को विज़ुअल तौर पर टेस्ट करने के बजाय, ऐसा एचटीएमएल "हार्नेस" बनाना बेहतर होगा जो सिर्फ़ कुछ कॉम्पोनेंट को रेंडर करता हो. खास तौर पर, ऐसा हो सकता है कि रिस्पॉन्सिव यूआई ट्रिगर करने के लिए, अलग-अलग स्क्रीन साइज़ में हो. यह पूरी तरह से JSDOM या इससे मिलते-जुलते फ़्रेमवर्क का इस्तेमाल करने से ज़्यादा मुश्किल है.
विज़ुअल टेस्ट के काम न करना, अन्य तरह की समस्याओं का एक अच्छा सिग्नल हो सकता है. हालांकि, मुश्किल यूज़र इंटरफ़ेस (यूआई) विज़ुअल टेस्ट में ऐसी वजहों से फ़ेल हो सकता है जिनकी आपको जांच नहीं की जा रही है. जैसे, यूआई के लुक में बदलाव करने वाली दूसरी नई सुविधाएं या यहां तक कि इमोजी को पुराने वर्शन से अलग तरीके से रेंडर करने वाला नया ओएस वर्शन भी.
शुरू से अंत तक के टेस्ट
शुरू से अंत तक के टेस्ट, आम तौर पर टेस्टिंग पिरामिड के सबसे ऊपर होते हैं. ये वेब ऐप्लिकेशन या वेबसाइट के पूरे अनुभव के बारे में जानकारी देती हैं, जो शायद किसी सुविधा के बारे में होती है. आम तौर पर, ये ऐसे ब्राउज़र के अंदर होती हैं जिसे WebdriverIO, Selenium या Puppeteer जैसे एजेंट कंट्रोल करते हैं. ये कोड बेस को कम या ज़्यादा चला सकते हैं, क्योंकि इन्हें प्रोडक्शन में डिप्लॉय किया जाता है. हालांकि, इन्हें अक्सर लोकल होस्ट पर दिखाया जाता है.
आपकी साइट के आधार पर, इसमें टेस्ट उपयोगकर्ता के तौर पर लॉग इन करना, बड़ी कार्रवाइयां करना, और इस बात की पुष्टि करना शामिल हो सकता है कि आपकी साइट या सिस्टम सही स्थिति में है. हम आगे सेक्शन में इस तरह के टेस्ट के और उदाहरण शामिल करेंगे, क्योंकि वे बहुत ताकतवर हो सकते हैं, लेकिन कभी-कभी उन्हें मैनेज करना मुश्किल होता है.
कॉन्टेंट को आसान बनाने के कुछ तरीकों में, उनके स्कोप को कम करना या ज़रूरत के हिसाब से खास कॉम्पोनेंट का मज़ाक़ बनाना शामिल हो सकता है. उदाहरण के लिए, अगर उपयोगकर्ताओं को आपकी साइट पर साइन इन करना है, लेकिन वह सुविधा जिसकी टेस्टिंग की जा रही है वह साइन इन नहीं है, तो आप टेस्ट एनवायरमेंट के लिए फ़्लैग सेट कर सकते हैं. इससे टेस्ट कंट्रोलर, साइन इन किए बिना या उससे जुड़ी कुकी बनाए बिना, उपयोगकर्ता के तौर पर काम कर सकेगा.
हालांकि, एंड-टू-एंड टेस्ट, अपने कोडबेस के बड़े-बड़े क्रॉस-सेक्शन में एक साथ टेस्ट करने का एक काफ़ी असरदार तरीका हो सकते हैं, लेकिन बाहरी सिस्टम पर निर्भर होने की वजह से ऐसे बड़े पैमाने पर किए जाने वाले टेस्ट में अस्थिर या गैर-भरोसेमंद होने का खतरा होता है. वे अक्सर आपके डेटाबेस में बहुत सारा टेस्ट डेटा छोड़ सकते हैं, जैसे कि अगर हर टेस्ट में कोई एंट्री बनाई जाती है या उसमें बदलाव किया जाता है. इस तरह बचा हुआ डेटा इकट्ठा करने से यह पता लगाना मुश्किल हो सकता है कि टेस्ट कैसे काम करता है.
एपीआई टेस्टिंग
एपीआई टेस्ट का मतलब, आपके सॉफ़्टवेयर के एपीआई के काम करने के तरीके की पुष्टि करना है. इसके अलावा, एपीआई टेस्ट के काम करने के तरीके की पुष्टि करने के लिए, असल दुनिया (शायद लाइव) एपीआई को ऐक्सेस करना भी हो सकता है. दोनों ही तरीकों से, यह सिस्टम के बीच ऐब्स्ट्रैक्शन को टेस्ट करता है. यह जांच की जाती है कि इंटिग्रेशन टेस्ट की तरह, वे सिस्टम एक-दूसरे से कैसे जुड़ेंगे.
आप जिन सिस्टम के बीच कनेक्शन की जांच कर रहे हैं, ये टेस्ट उनके ओवरहेड के बिना, इंटिग्रेशन जांच की शुरुआत कर सकते हैं. हालांकि, असल दुनिया के सिस्टम के टेस्ट में गड़बड़ी हो सकती है.
अन्य तरह का डेटा
टेस्टिंग करने के कई ऐसे दूसरे तरीके भी हैं जो आपके लिए मददगार हो सकते हैं. हालांकि, यह आपके सोर्स पर निर्भर करता है. दिलचस्प उदाहरणों में ये शामिल हैं:
- मैन्युअल रूप से टेस्ट करना.
- मंज़ूरी टेस्ट, एक तरह की मैन्युअल टेस्टिंग, जिसे Agile ने लोकप्रिय किया है, इस बात की पुष्टि करता है कि प्रॉडक्ट "उपयोगकर्ता की ज़रूरतों को पूरा करता है".
- गड़बड़ी की जांच करने का मतलब रैंडम डेटा डालकर यह देखना है कि क्या हो रहा है. इससे यह पक्का किया जाता है कि गलत डेटा डालने पर, साइट क्रैश न हो जाए.
- फ़ेलियर टेस्ट, जान-बूझकर किए गए कॉम्प्लेक्स सिस्टम की गड़बड़ियों को सिम्युलेट करता है, जैसे कि नेटवर्क की गड़बड़ी. इससे यह पक्का किया जाता है कि जांच में इस्तेमाल किया जा रहा कोड कंट्रोल किए गए तरीके से काम करे.
- बिल्ड टेस्टिंग से यह पुष्टि होती है कि कोडबेस के बिल्ड आर्टफ़ैक्ट जनरेट किए जा सकते हैं. इसके लिए, यह जांच करना ज़रूरी है कि कोड मौजूद है या नहीं या उसका कॉन्टेंट क्या है. इस टेस्ट टाइप से, किसी कॉम्प्लेक्स कॉन्टेंट मैनेजमेंट सिस्टम के आउटपुट की जांच करने में मदद मिल सकती है.
कोड कवरेज
यह मापना मुमकिन है कि आपके कितने प्रतिशत कोड की जाँच ऑटोमेटेड जाँचों से की गई है और समय-समय पर इसे एक आंकड़े के रूप में रिपोर्ट किया जा सकता है. हम 100% कोड कवरेज पर फ़ोकस करने की सलाह नहीं देते. ऐसा करने से, बेवजह का काम हो सकता है. साथ ही, टेस्ट को आसान या खराब तरीके से डिज़ाइन किया जा सकता है, जिनमें इस्तेमाल के मुख्य उदाहरणों को शामिल नहीं किया गया है.
टेस्ट लिखते या उन पर काम करते समय, कवरेज भी एक फ़ायदेमंद टूल हो सकता है. खास तौर पर, इंटिग्रेशन टेस्ट. किसी एक टेस्ट से टेस्ट किए गए कोड का प्रतिशत या लाइन-दर-लाइन ब्रेकडाउन दिखाया जा सकता है. इससे आपको यह जानकारी मिल सकती है कि क्या मौजूद नहीं है या आगे क्या टेस्ट किया जा सकता है.
रिसॉर्स
जांचें कि आपको कितना समझ आया
इनमें से किस तरह की जांच के बारे में पता है?