पिरामिड या केकड़ा? टेस्टिंग की ऐसी रणनीति ढूंढें जो

जानें कि अलग-अलग तरह की टेस्टिंग को एक ऐसी रणनीति में कैसे जोड़ा जाए जो आपके प्रोजेक्ट के हिसाब से हो.

Ramona Schwering

आपका फिर से स्वागत है! पिछले लेख में, अलग-अलग तरह के टेस्ट को कैसे इस्तेमाल करें और उनमें क्या शामिल है, इस बारे में ज़्यादा जानकारी दी गई थी. साथ ही, टेस्ट के टाइप की परिभाषाओं के बारे में भी बताया गया था. क्या आपको यह छोटी मीम इमेज याद है? आपको शायद यह जानने में दिलचस्पी हो कि जांच के जिन अलग-अलग टाइप के बारे में आपने जाना है वे एक साथ कैसे काम कर सकते हैं.

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

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

आइए, इन रणनीतियों के बारे में ज़्यादा जानें और उनके नामों का मतलब जानें.

टेस्टिंग के लक्ष्य तय करना: आपको इन टेस्ट से क्या हासिल करना है?

अच्छी रणनीति बनाने से पहले, टेस्टिंग का लक्ष्य तय करें. आपके हिसाब से, आपके ऐप्लिकेशन की जांच कब पूरी हो जाती है?

टेस्टिंग के मामले में, डेवलपर के लिए ज़्यादा टेस्ट कवरेज हासिल करना अक्सर सबसे अहम लक्ष्य माना जाता है. क्या यह हमेशा सबसे अच्छा तरीका है? टेस्टिंग की रणनीति तय करते समय, उपयोगकर्ताओं की ज़रूरतों को ध्यान में रखना भी ज़रूरी है.

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

आपके टेस्ट, आपके सॉफ़्टवेयर के इस्तेमाल के तरीके से जितने ज़्यादा मिलते-जुलते होंगे, आपको उतना ही ज़्यादा भरोसा मिलेगा.

केंट सी. डॉड्स

केंट इसे टेस्ट में आत्मविश्वास बढ़ाने के तौर पर बताते हैं. अपने हिसाब से टेस्टिंग टाइप चुनकर, उपयोगकर्ताओं के करीब पहुंचने पर, आपको अपने टेस्ट के मान्य नतीजों पर ज़्यादा भरोसा होगा. दूसरे शब्दों में, पिरामिड में ऊपर चढ़ने पर, आपको ज़्यादा आत्मविश्वास मिलता है. लेकिन, पिरामिड क्या है?

टेस्टिंग की रणनीतियां तय करना: टेस्टिंग की रणनीति चुनने का तरीका

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

क्लासिक: टेस्ट पिरामिड

जांच की रणनीतियों को खोजते ही, आपको सबसे पहले टेस्ट ऑटोमेशन पिरामिड दिखेगा. माइक कोहन ने "Agile के साथ सफलता" नाम की अपनी किताब में इस कॉन्सेप्ट को पेश किया था. बाद में, मार्टिन फ़ाउलर ने अपने प्रैक्टिकल टेस्ट पिरामिड लेख में इस कॉन्सेप्ट के बारे में ज़्यादा जानकारी दी. पिरामिड को विज़ुअल तौर पर इस तरह दिखाया जा सकता है:

इस ड्रॉइंग में दिखाया गया है कि टेस्ट पिरामिड में तीन लेयर होती हैं:

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

2. इंटिग्रेशन. ये टेस्ट पिरामिड के बीच में होते हैं, क्योंकि इनका ऐक्सीक्यूशन स्पीड ठीक-ठाक होता है. हालांकि, यूनिट टेस्ट की तुलना में ये आपको उपयोगकर्ता के करीब लाते हैं. इंटिग्रेशन टेस्ट का एक उदाहरण, एपीआई टेस्ट है. कॉम्पोनेंट टेस्ट को भी इस टाइप के तौर पर बांटा जा सकता है.

3. E2E टेस्ट (इन्हें यूज़र इंटरफ़ेस (यूआई) टेस्ट भी कहा जाता है). ये टेस्ट, किसी असली उपयोगकर्ता और उसके इंटरैक्शन को सिम्युलेट करते हैं. ऐसे टेस्ट को पूरा करने में ज़्यादा समय लगता है. इसलिए, ये टेस्ट ज़्यादा महंगे होते हैं. ये पिरामिड के सबसे ऊपर होते हैं.

कॉन्फ़िडेंस बनाम संसाधन

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

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

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

1. अलग-अलग लेवल पर टेस्ट लिखें.
2. आपका लेवल जितना ज़्यादा होगा, आपको उतने ही कम टेस्ट करने होंगे.

पिरामिड का नया वर्शन! टेस्ट पिरामिड के अडैप्टेशन

कई सालों से, पिरामिड के बारे में चर्चा की जा रही है. पिरामिड में, टेस्टिंग की रणनीतियों को बहुत आसान बना दिया गया है. इसमें टेस्टिंग के कई टाइप शामिल नहीं हैं और यह अब असल दुनिया के सभी प्रोजेक्ट के हिसाब से नहीं है. इसलिए, यह गुमराह करने वाला हो सकता है. क्या पिरामिड का आकार खराब हो गया है? Guillermo Rauch का इस बारे में यह कहना है:

टेस्ट लिखें. बहुत ज़्यादा नहीं. ज़्यादातर इंटिग्रेशन.

गिल्र्मो राउच की ओर से लिखा गया

इस विषय पर अक्सर इस कोटेशन का इस्तेमाल किया जाता है. इसलिए, आइए इसे समझते हैं:

• "टेस्ट लिखें". ऐसा इसलिए, क्योंकि इससे लोगों का भरोसा बढ़ता है. साथ ही, इसे मैनेज करने में भी कम समय लगता है.
• "ज़्यादा नहीं". 100% कवरेज हमेशा अच्छा नहीं होता, क्योंकि तब आपकी टेस्टिंग को प्राथमिकता नहीं दी जाती और रखरखाव का काम बहुत ज़्यादा होता है.
• "ज़्यादातर इंटिग्रेशन". यहां भी इंटिग्रेशन टेस्ट पर ज़ोर दिया गया है: ये टेस्ट, कारोबार के लिए सबसे ज़्यादा अहम होते हैं. इनकी मदद से, आपको हर दिन ज़्यादा कॉन्फ़िडेंस लेवल मिलता है. साथ ही, ये टेस्ट कम समय में पूरे होते हैं.

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

टेस्ट डायमंड

पहले अडैप्टेशन में, यूनिट टेस्टिंग पर ज़्यादा ध्यान नहीं दिया जाता, जैसा कि टेस्ट पिरामिड में देखा गया है. मान लें कि आपने यूनिट टेस्ट के लिए 100% कवरेज हासिल कर ली है. हालांकि, अगली बार रीफ़ैक्टर करते समय, आपको इनमें से कई यूनिट टेस्ट अपडेट करने होंगे. ऐसा हो सकता है कि आप इन्हें स्किप करना चाहें. इसलिए, वे खराब हो जाते हैं.

इस वजह से, इंटिग्रेशन टेस्टिंग पर ज़्यादा फ़ोकस करने के साथ-साथ, यह आकार दिख सकता है:

पिरामिड, हीरे में बदल जाता है. आपको पिछली तीन लेयर दिख सकती हैं, लेकिन अलग साइज़ में. साथ ही, यूनिट लेयर काट दी गई है:

• यूनिट. यूनिट टेस्ट को उसी तरह लिखें जिस तरह आपने पहले उन्हें तय किया था. हालांकि, इनकी संख्या कम हो जाती है. इसलिए, सिर्फ़ सबसे ज़रूरी मामलों को प्राथमिकता दी जाती है और उन्हें कवर किया जाता है.
• इंटिग्रेशन. आपको इंटिग्रेशन टेस्ट के बारे में पता है. यह टेस्ट, एक इकाई के कॉम्बिनेशन की जांच करता है.
• E2E. यह लेयर, टेस्ट पिरामिड की तरह ही यूज़र इंटरफ़ेस (यूआई) टेस्ट को मैनेज करती है. ध्यान रखें कि सिर्फ़ सबसे ज़रूरी टेस्ट केस के लिए E2E टेस्ट लिखें.

हनीकॉम्ब की जांच करना

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

इस आकार से हमें मधुमक्खी के छत्ते की याद आती है. इसलिए, इसका नाम हनीकॉम्ब रखा गया है. इसमें ये लेयर शामिल हैं:

• इंटिग्रेट किए गए टेस्ट. Spotify के लेख में, जे. B. Rainsberger ने इस लेयर को इस तरह से परिभाषित किया है: “यह एक ऐसा टेस्ट है जो किसी दूसरे सिस्टम के सही होने या न होने के आधार पर पास या फ़ेल होगा.” ऐसे टेस्ट में बाहरी डिपेंडेंसी होती हैं, जिन पर आपको ध्यान देने की ज़रूरत होती है. इसके उलट, हो सकता है कि आपका सिस्टम एक ऐसी डिपेंडेंसी हो जो दूसरे सिस्टम को गड़बड़ी में डाल दे. दूसरे उदाहरणों में E2E टेस्ट की तरह ही, इन टेस्ट का इस्तेमाल सावधानी से करें. इन्हें सिर्फ़ सबसे ज़रूरी मामलों में इस्तेमाल करें.
• इंटिग्रेशन टेस्ट. अन्य अडैप्टेशन की तरह ही, आपको इस लेयर पर फ़ोकस करना चाहिए. इसमें ऐसे टेस्ट शामिल होते हैं जो आपकी सेवा की पुष्टि, अन्य सेवाओं के साथ मिलकर करते हैं. हालांकि, यह पुष्टि अलग-अलग तरीके से की जाती है. इसका मतलब है कि टेस्ट में कुछ अन्य सिस्टम भी शामिल होंगे और इंटरैक्शन पॉइंट पर फ़ोकस किया जाएगा. उदाहरण के लिए, एपीआई टेस्ट के ज़रिए.
• लागू करने की जानकारी की जांच. ये टेस्ट, यूनिट टेस्ट से मिलते-जुलते हैं. ये टेस्ट, कोड के उन हिस्सों पर फ़ोकस करते हैं जो अपने-आप अलग होते हैं और इसलिए, इनमें अपनी अंदरूनी जटिलता होती है.

टेस्टिंग की इस रणनीति के बारे में ज़्यादा जानने के लिए, मार्टिन फ़ाउलर की पोस्ट देखें, जिसमें टेस्ट पिरामिड की तुलना हनीकॉम्ब से की गई है. साथ ही, Spotify का मूल लेख भी पढ़ें.

टेस्टिंग ट्रॉफ़ी

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

टेस्टिंग ट्रॉफी, टेस्ट के बारे में थोड़े अलग तरीके से जानकारी देने वाली एक एनालॉजी है. इसमें चार लेयर होते हैं:

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

टेस्टिंग ट्रॉफी के बारे में ज़्यादा जानने के लिए, केंट सी की ब्लॉग पोस्ट देखें. Dodds की यह रिपोर्ट पढ़ें.

यूज़र इंटरफ़ेस (यूआई) पर फ़ोकस करने वाले कुछ और तरीके

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

आइस कोन और केकड़े की जांच करना

असल में, टेस्टिंग पिरामिड के दो ऐसे वर्शन हैं जो यूज़र इंटरफ़ेस (यूआई) पर फ़ोकस करने वाले टेस्टिंग के तरीकों पर ज़्यादा ध्यान देते हैं. दोनों में ही ज़्यादा कॉन्फ़िडेंस का फ़ायदा मिलता है. हालांकि, टेस्ट को पूरा होने में ज़्यादा समय लगने की वजह से, इनकी लागत ज़्यादा होती है.

पहला, टेस्ट आइस कोन, उलटे पिरामिड की तरह दिखता है. मैन्युअल टेस्टिंग के चरण के बिना, इसे टेस्टिंग पिज़्ज़ा भी कहा जाता है.

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

टेस्ट क्रैब, टेस्ट आइस कोन से मिलता-जुलता है. हालांकि, इसमें E2E और विज़ुअल टेस्टिंग पर ज़्यादा ध्यान दिया जाता है:

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

ये दोनों टेस्टिंग की रणनीतियां ज़्यादा महंगी हैं, लेकिन इनका अपना महत्व है. उदाहरण के लिए, छोटे प्रोजेक्ट में जहां कम टेस्ट की ज़रूरत होती है या कम जटिलता को कवर करना होता है. इस मामले में, इंटिग्रेशन टेस्टिंग पर फ़ोकस करने वाली पूरी टेस्टिंग की रणनीति, ज़रूरत से ज़्यादा हो सकती है.

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

काम की सलाह: चलिए रणनीति बनाते हैं!

अब आपको टेस्टिंग की सबसे सामान्य रणनीतियों के बारे में पता चल गया है. आपने टेस्ट पिरामिड के क्लासिक वर्शन से शुरुआत की और इसके कई तरह के अडैप्टेशन के बारे में जाना. अब आपको अपने प्रॉडक्ट के लिए इनका आकलन करना होगा और यह तय करना होगा कि आपके प्रोजेक्ट के लिए कौनसा सबसे अच्छा है. इस सवाल का जवाब, सभी के पसंदीदा "यह इस बात पर निर्भर करता है" से शुरू होना चाहिए. हालांकि, इससे यह सटीक नहीं हो जाता.

यहां बताई गई टेस्टिंग की रणनीतियों में से सबसे सही रणनीति चुनना, आपके ऐप्लिकेशन पर निर्भर करता है. यह आपके आर्किटेक्चर, आपकी ज़रूरतों, और सबसे अहम बात यह है कि यह आपके उपयोगकर्ताओं और उनकी ज़रूरतों के हिसाब से होना चाहिए. यह हर ऐप्लिकेशन के हिसाब से अलग-अलग हो सकता है. यह पूरी तरह से सामान्य है. याद रखें कि आपका सबसे अहम लक्ष्य, उपयोगकर्ताओं को बेहतर अनुभव देना है, न कि किताबों में दी गई परिभाषा.

असल दुनिया के टेस्ट को अलग-अलग करना और उनके बारे में अलग से बताना मुश्किल होता है. मार्टिन फ़ाउलर भी अलग-अलग परिभाषाओं के अच्छे पहलू पर ज़ोर देते हैं. जैसे, यूनिट टेस्ट के मामले में. जस्टिन सीरल्स ने अपने ट्वीट में सही तरीके से बताया है:

[…] ऐसे टेस्ट लिखें जो साफ़ तौर पर सीमाएं तय करते हों, तेज़ी से और भरोसेमंद तरीके से काम करते हों, और सिर्फ़ काम की वजहों से फ़ेल हों.

जस्टिन सीर्ल्स की ओर से लिखा गया

उन टेस्ट पर फ़ोकस करें जो उपयोगकर्ताओं को मिलने वाली असल गड़बड़ियों की जानकारी देते हैं. साथ ही, अपने लक्ष्य से ध्यान न हटाएं. टेस्ट को उपयोगकर्ता के फ़ायदे के लिए डिज़ाइन किया जाना चाहिए, न कि सिर्फ़ 100% कवरेज देने या यह तय करने के लिए कि किस तरह के टेस्ट का कितना प्रतिशत लिखना है.

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