तय करें कि आपको किस चीज़ की जांच करनी है और किससे नहीं.
पिछले लेख में, टेस्ट केस की बुनियादी बातों और उनके बारे में जानकारी दी गई है. इस लेख में, तकनीकी नज़रिए से टेस्ट केस बनाने के बारे में विस्तार से बताया गया है. साथ ही, यह भी बताया गया है कि हर टेस्ट में क्या शामिल किया जाना चाहिए और क्या नहीं. इसके तहत, आपको "क्या टेस्ट करना चाहिए" या "क्या टेस्ट नहीं करना चाहिए" जैसे बहुत पुराने सवालों के जवाब मिलेंगे.
सामान्य दिशा-निर्देश और पैटर्न
ध्यान रखें कि खास पैटर्न और पॉइंट का ध्यान रखना ज़रूरी होता है. इससे कोई फ़र्क़ नहीं पड़ता कि यूनिट, इंटिग्रेशन या एंड-टू-एंड टेस्ट किए जा रहे हैं या नहीं. इन सिद्धांतों को दोनों तरह की जांच पर लागू किया जा सकता है और लागू भी किया जा सकता है. इसलिए, ये शुरुआत करने के लिए एक अच्छी जगह है.
इसे आसान रखें
जब टेस्ट लिखने की बात आती है, तो सबसे ज़रूरी बात यह है कि आप उसे आसान रखें. दिमाग की क्षमता को देखना ज़रूरी है. मुख्य प्रोडक्शन कोड ज़्यादा जगह लेता है, जिससे अतिरिक्त जटिलता की संभावना कम हो जाती है. यह खास तौर पर टेस्टिंग के लिए सही है.
अगर हेडस्पेस कम उपलब्ध है, तो टेस्ट करने के दौरान आपको ज़्यादा राहत मिल सकती है. इसलिए, टेस्टिंग में आसान भाषा को प्राथमिकता देना ज़रूरी है. असल में, योनी गोल्डबर्ग की JavaScript की जांच करने के सबसे सही तरीके, गोल्डन रूल की अहमियत पर ज़ोर देते हैं—आपका टेस्ट एक असिस्टेंट की तरह होना चाहिए, न कि गणित के किसी मुश्किल फ़ॉर्मूले की तरह. दूसरे शब्दों में, आपको पहली नज़र में ही अपने टेस्ट का मकसद समझ जाना चाहिए.
आपको सभी तरह के टेस्ट को आसान बनाना चाहिए, फिर चाहे वे कितनी भी मुश्किल क्यों न हों. असल में, कोई टेस्ट जितना मुश्किल होगा, उसे आसान बनाना उतना ही ज़रूरी होगा. इसे हासिल करने का एक तरीका है, फ़्लैट टेस्ट डिज़ाइन का इस्तेमाल करना. इसमें टेस्ट को जितना हो सके उतना आसान रखा जाता है और सिर्फ़ ज़रूरी चीज़ों की जांच की जाती है. इसका मतलब है कि हर टेस्ट में सिर्फ़ एक टेस्ट केस होना चाहिए. साथ ही, टेस्ट केस का फ़ोकस किसी एक, खास फ़ंक्शन या सुविधा की जांच करने पर होना चाहिए.
इसे इस नज़रिए से समझें: किसी फ़ेल हो रहे टेस्ट को पढ़ने में हुई गड़बड़ी का पता आसानी से लगाया जा सकता है. इसलिए, जांच को आसान और समझने में आसान रखना बहुत ज़रूरी है. इससे आपको कोई भी समस्या होने पर उसका तुरंत पता लगाने और उसे ठीक करने में मदद मिलती है.
देखें कि क्या सही है
सपाट टेस्ट डिज़ाइन, फ़ोकस को बढ़ावा देता है और यह पक्का करने में मदद करता है कि आपके टेस्ट काम के हों. याद रखें, आपको सिर्फ़ जानकारी पाने के लिए टेस्ट तैयार नहीं करने चाहिए, बल्कि इनका मकसद भी होना चाहिए.
लागू करने की जानकारी की जांच न करें
टेस्टिंग में एक आम समस्या यह है कि टेस्ट को अक्सर लागू करने की जानकारी की जांच करने के लिए डिज़ाइन किया जाता है. जैसे, कॉम्पोनेंट में सिलेक्टर का इस्तेमाल करना या शुरू से अंत तक के टेस्ट. लागू करने की जानकारी में वे चीज़ें शामिल होती हैं जिनके बारे में आपके कोड का इस्तेमाल करने वाले लोग आम तौर पर इस्तेमाल नहीं करेंगे, नहीं देखेंगे या जिनके बारे में नहीं जानते होंगे. इससे जांच में दो बड़ी समस्याएं हो सकती हैं: फ़ॉल्स नेगेटिव और फ़ॉल्स पॉज़िटिव.
टेस्ट के फ़ेल होने पर फ़ॉल्स नेगेटिव होते हैं, भले ही जांचा गया कोड सही हो. ऐसा तब हो सकता है, जब ऐप्लिकेशन कोड के रीफ़ैक्टरिंग की वजह से, लागू करने से जुड़ी जानकारी में बदलाव हो. वहीं दूसरी ओर, टेस्ट पास हो जाने पर फ़ॉल्स पॉज़िटिव आते हैं, भले ही टेस्ट किया जा रहा कोड गलत हो.
अपने अलग-अलग तरह के उपयोगकर्ताओं को ध्यान में रखकर, इस समस्या को हल किया जा सकता है. असली उपयोगकर्ता और डेवलपर के काम करने का तरीका अलग-अलग हो सकता है और वे कोड के साथ अलग-अलग तरह से इंटरैक्ट कर सकते हैं. टेस्ट को प्लान करते समय यह ध्यान रखना ज़रूरी है कि उपयोगकर्ताओं को क्या दिखेगा या वे क्या करेंगे. साथ ही, टेस्ट को लागू करने की जानकारी के बजाय, इन चीज़ों पर निर्भर बनाएं.
उदाहरण के लिए, जिन सिलेक्टर में बदलाव होने की संभावना कम होती है उन्हें चुनने से टेस्ट ज़्यादा भरोसेमंद हो सकते हैं: सीएसएस सिलेक्टर के बजाय, डेटा-एट्रिब्यूट. ज़्यादा जानकारी के लिए, केंट सी॰ इस विषय पर डॉड्स का लेख या हमारे साथ बने रहें—इस विषय पर एक लेख बाद में आने वाला है.
मॉकिंग: कंट्रोल बनाए रखें
मॉकिंग एक बहुत बड़ा कॉन्सेप्ट है. इसका इस्तेमाल यूनिट टेस्टिंग में किया जाता है. इसके अलावा, कभी-कभी इंटिग्रेशन टेस्टिंग में भी इसका इस्तेमाल किया जाता है. इसमें, नकली डेटा या कॉम्पोनेंट बनाना शामिल है, ताकि उन डिपेंडेंसी को सिम्युलेट किया जा सके जिनका ऐप्लिकेशन पर पूरा कंट्रोल होता है. इसकी मदद से, आइसोलेटेड टेस्टिंग की जा सकती है.
टेस्ट में मॉक का इस्तेमाल करने से बेहतर अनुमान मिलता है. साथ ही, इससे समस्याओं को अलग-अलग करने में मदद मिलती है और परफ़ॉर्मेंस बेहतर होती है. अगर आपको कोई ऐसी जांच करानी है जिसमें किसी व्यक्ति की भागीदारी ज़रूरी हो (जैसे, पासपोर्ट की पुष्टि), तो आपको मॉक का इस्तेमाल करके इसे छिपाना होगा. इन सभी वजहों से, मॉक टूल का इस्तेमाल भी किया जा सकता है.
साथ ही, मॉक टेस्ट से जांच के नतीजे पर गलत असर पड़ सकता है, क्योंकि यह सिर्फ़ मज़ाक़ में होता है, न कि असली उपयोगकर्ता अनुभव पर. इसलिए, मॉक और स्टब का इस्तेमाल करते समय सावधानी बरतें.
क्या आपको शुरू से अंत तक के टेस्ट में नकल करनी चाहिए?
आम तौर पर नहीं. हालांकि, मज़ाक़ उड़ाने से कई बार मदद मिल सकती है—इसलिए, इस बात को पूरी तरह से खारिज न करें.
मान लें कि आपको किसी ऐसी सुविधा के लिए टेस्ट का अनुरोध करना है जिसमें, पेमेंट की सेवा देने वाली तीसरे पक्ष की कंपनी शामिल है. आप उस सैंडबॉक्स एनवायरमेंट में हैं जो उन्होंने उपलब्ध कराया है. इसका मतलब है कि कोई असल लेन-देन नहीं हो रहा है. माफ़ करें, सैंडबॉक्स ठीक से काम नहीं कर रहा है. इस वजह से, आपके टेस्ट फ़ेल हो जाते हैं. यह समस्या, पेमेंट की सेवा देने वाली कंपनी को पूरी करनी होगी. बस सेवा देने वाली कंपनी के ज़रिए समस्या हल होने का इंतज़ार करें.
इस मामले में, उन सेवाओं पर निर्भरता कम करना ज़्यादा फ़ायदेमंद हो सकता है जिन्हें आप कंट्रोल नहीं कर सकते. हालांकि, इंटिग्रेशन या शुरू से अंत तक के टेस्ट में, मॉकिंग का इस्तेमाल ध्यान से करने की सलाह दी जाती है. ऐसा इसलिए, क्योंकि इससे आपके टेस्ट का कॉन्फ़िडेंस लेवल कम हो जाता है.
टेस्ट की खास बातें: क्या करें और क्या न करें
कुल मिलाकर, टेस्ट में क्या शामिल होता है? क्या टेस्टिंग टाइप के बीच कोई अंतर है? आइए, मुख्य टेस्टिंग टाइप के हिसाब से तैयार किए गए कुछ खास पहलुओं के बारे में बारीकी से जानते हैं.
अच्छे यूनिट टेस्ट से क्या होता है?
एक आदर्श और असरदार यूनिट टेस्ट में ये चीज़ें होनी चाहिए:
- खास पहलुओं पर फ़ोकस करें.
- स्वतंत्र रूप से काम करें.
- इसमें छोटे स्तर की स्थितियों को शामिल किया जाता है.
- जानकारी देने वाले नामों का इस्तेमाल करें.
- अगर एएए पैटर्न लागू हो, तो इसका पालन करें.
- बेहतर टेस्ट कवरेज की गारंटी.
| ऐसा करें ✅ | ऐसा न करें ❌ |
|---|---|
| टेस्ट को जितना हो सके उतना छोटा रखें. हर टेस्ट केस के लिए, एक चीज़ की जांच करें. | बड़ी यूनिट में टेस्ट लिखें. |
| टेस्ट को हमेशा अलग रखें और उन चीज़ों का मॉक करें जो आपकी यूनिट से बाहर हैं. | अन्य कॉम्पोनेंट या सेवाएं शामिल करें. |
| जांच को अलग-अलग रखें. | पिछले टेस्ट पर भरोसा करें या टेस्ट का डेटा शेयर करें. |
| अलग-अलग स्थितियों और पाथ के बारे में जानें. | खुद को खुश करने वाले पाथ या नेगेटिव टेस्ट तक सीमित रखें. |
| जांच के लिए जानकारी देने वाले टाइटल इस्तेमाल करें, ताकि आप तुरंत देख सकें कि जांच किस बारे में है. | सिर्फ़ फ़ंक्शन के नाम के हिसाब से जांच करें, न कि नतीजे के तौर पर काफ़ी जानकारी देने वाला: testBuildFoo() या testGetId(). |
| खास तौर पर, इस चरण में, अच्छे कोड कवरेज या टेस्ट केस की एक बड़ी रेंज को आज़माएं. | हर क्लास से डेटाबेस (I/O) लेवल तक टेस्ट करें. |
एक अच्छे इंटिग्रेशन टेस्ट से क्या होता है?
एक आदर्श इंटिग्रेशन टेस्ट, यूनिट टेस्ट के साथ भी कुछ शर्तें शेयर करता है. हालांकि, आपको कुछ और बिंदुओं पर विचार करना होगा. इंटिग्रेशन की बेहतरीन जांच में ये चीज़ें शामिल होनी चाहिए:
- कॉम्पोनेंट के बीच इंटरैक्शन सिम्युलेट करें.
- असल दुनिया की घटनाओं को कवर करें और मॉक या स्टब का इस्तेमाल करें.
- परफ़ॉर्मेंस पर ध्यान दें.
| ऐसा करें ✅ | ऐसा न करें ❌ |
|---|---|
| इंटिग्रेशन पॉइंट की जांच करें: पुष्टि करें कि हर यूनिट को एक-दूसरे के साथ इंटिग्रेट करने पर, वह एक साथ बेहतर तरीके से काम करती हैं. | हर यूनिट को अलग-अलग करके टेस्ट करें. यूनिट टेस्ट का यही काम है. |
| असल दुनिया की स्थितियों की जांच करें: असल दुनिया के डेटा से मिले टेस्ट डेटा का इस्तेमाल करें. | दोहराए जाने वाले अपने-आप जनरेट हुए टेस्ट डेटा या ऐसा अन्य डेटा का इस्तेमाल करें जो असल में इस्तेमाल के उदाहरण से मेल न खाता हो. |
| मॉक और स्टब का इस्तेमाल बाहरी डिपेंडेंसी के लिए करें, ताकि आप टेस्ट को पूरा कंट्रोल कर सकें. | तीसरे पक्ष की सेवाओं के लिए डिपेंडेंसी बनाएं. उदाहरण के लिए, बाहरी सेवाओं के लिए नेटवर्क अनुरोध. |
| हर टेस्ट के पहले और बाद में, क्लीन अप रूटीन का इस्तेमाल करें. | अपने टेस्ट में क्लीन-अप के तरीके इस्तेमाल करना भूल जाएं. ऐसा न करने पर, टेस्ट के नतीजे पूरे नहीं हो सकते या जांच के नतीजे गलत साबित हो सकते हैं. ऐसा, टेस्ट आइसोलेशन की कमी की वजह से होता है. |
शुरू से अंत तक के अच्छे टेस्ट से क्या होता है?
एक बेहतर टेस्ट में ये चीज़ें शामिल होनी चाहिए:
- उपयोगकर्ता के इंटरैक्शन को कॉपी करें.
- ज़रूरी स्थितियों को शामिल करें.
- कई लेयर में.
- एसिंक्रोनस ऑपरेशन मैनेज करें.
- नतीजों की पुष्टि करें.
- परफ़ॉर्मेंस पर ध्यान दें.
| ऐसा करें ✅ | ऐसा न करें ❌ |
|---|---|
| एपीआई से चलने वाले शॉर्टकट का इस्तेमाल करें. ज़्यादा जानें. | हर चरण के लिए, यूज़र इंटरफ़ेस (यूआई) इंटरैक्शन का इस्तेमाल करें. इसमें beforeEach हुक भी शामिल है. |
| हर टेस्ट से पहले, क्लीन अप रूटीन का इस्तेमाल करें. यूनिट और इंटिग्रेशन टेस्ट की तुलना में, टेस्ट आइसोलेशन का ज़्यादा ध्यान रखें, क्योंकि इससे खराब असर का खतरा ज़्यादा होता है. | हर बार टेस्ट के बाद मेमोरी खाली करना भूल जाएं. अगर बचा हुआ डेटा, डेटा या खराब असर को हटाया नहीं जाता है, तो बाद में किए जाने वाले अन्य टेस्ट पर इनका असर पड़ेगा. |
| शुरू से अंत तक के टेस्ट को सिस्टम टेस्ट के तौर पर देखें. इसका मतलब है कि आपको ऐप्लिकेशन के पूरे स्टैक की जांच करनी होगी. | हर यूनिट को अलग-अलग करके टेस्ट करें. यूनिट टेस्ट का यही काम है. |
| टेस्ट में, मॉकिंग का कम से कम इस्तेमाल करें या बिना मॉक का इस्तेमाल करें. अगर आपको बाहरी डिपेंडेंसी मॉक करना है, तो बहुत ध्यान से सोचें. | मॉक पर ज़्यादा भरोसा करें. |
| उदाहरण के लिए, एक ही टेस्ट में बड़ी स्थितियों को ओवर-टेस्ट न करके, परफ़ॉर्मेंस और वर्कलोड पर ध्यान दें. | शॉर्टकट का इस्तेमाल किए बिना, बड़े वर्कफ़्लो को कवर करें. |