जानें कि अलग-अलग टेस्टिंग टाइप को एक ऐसी रणनीति में कैसे शामिल करें जो आपके प्रोजेक्ट के हिसाब से सही हो.
आपका फिर से स्वागत है! पिछले लेख में, अलग-अलग तरह की टेस्टिंग का तरीका जानने और उसमें क्या-क्या शामिल है, इस बारे में काफ़ी बुनियादी काम किया गया था. साथ ही, टेस्टिंग टाइप की परिभाषाओं को बेहतर तरीके से समझाया गया था. क्या आपको यह छोटी मीम वाली इमेज याद है? आपने सोचा होगा कि टेस्ट करने के जिन तरीकों के बारे में आपने सीखा है, वे एक साथ कैसे काम कर सकते हैं.
इसके बाद, आपको इस बारे में ठीक-ठीक पता चलेगा. इस लेख में, इन टेस्टिंग टाइप को एक साथ इस्तेमाल करके सही रणनीतियां बनाने और अपने प्रोजेक्ट से मिलती-जुलती रणनीतियों को चुनने का तरीका बताया गया है.
रणनीतियों की तुलना कई आकारों से की जा सकती है, ताकि आप उनका मतलब बेहतर तरीके से समझ सकें. यहां अलग-अलग साइज़ और डेवलपमेंट के स्कोप वाली रणनीतियों की सूची दी गई है.
आइए, उन रणनीतियों के बारे में विस्तार से जानते हैं और उनके नाम का मतलब जानते हैं.
जांच के लक्ष्य तय करें: इन टेस्ट से क्या हासिल किया जा सकता है?
एक अच्छी रणनीति बनाने से पहले, अपने टेस्टिंग लक्ष्य का पता लगाएं. आपको कब लगता है कि आपके ऐप्लिकेशन की ठीक से जांच की गई है?
ऐप्लिकेशन की टेस्टिंग के लिए, डेवलपर का सबसे अहम लक्ष्य अक्सर ज़्यादा टेस्ट कवरेज पाना होता है. हालांकि, क्या यह हमेशा सबसे सही तरीका है? टेस्टिंग की रणनीति तय करते समय, अपने उपयोगकर्ताओं की ज़रूरतों को पूरा करने से जुड़ा एक और अहम पहलू भी हो सकता है.
डेवलपर के तौर पर, आपको कई अन्य ऐप्लिकेशन और डिवाइसों का भी इस्तेमाल किया जाता है. इस संबंध में, आप वह उपयोगकर्ता हैं जो “बस काम” करने के लिए इन सभी सिस्टम पर निर्भर करता है. इसके बदले में, आप अनगिनत डेवलपर पर निर्भर हैं कि वे अपने ऐप्लिकेशन और डिवाइस को बेहतर तरीके से चलाने के लिए अपना योगदान दें. डेवलपर के तौर पर, आपको भी इस भरोसे को बनाए रखने की कोशिश करनी होगी. इसलिए, आपका पहला लक्ष्य हमेशा काम करने वाला सॉफ़्टवेयर शिप करना और अपने उपयोगकर्ताओं को सेवा देना होना चाहिए. इसमें ऐप्लिकेशन की क्वालिटी को पक्का करने के लिए की जाने वाली जांचों पर भी लागू होती है. केंट सी॰ Dodds ने स्टैटिक बनाम यूनिट बनाम इंटिग्रेशन बनाम Frontend ऐप्लिकेशन के लिए E2E टेस्टिंग पोस्ट में इसे अच्छी तरह से समझाया है:
आपकी जांच, आपके सॉफ़्टवेयर के इस्तेमाल की तरह जितनी ज़्यादा मिलती-जुलती हैं, वे आपको उतना ही ज़्यादा भरोसा दे सकते हैं.
केंट सी॰ डॉड्स
केंट कहते हैं कि यह टेस्ट में, भरोसा जीतना है. सही टेस्टिंग टाइप चुनकर, आप उपयोगकर्ताओं के जितने करीब आएंगे, आपको सही नतीजे पाने के लिए टेस्ट पर उतना ज़्यादा भरोसा होगा. दूसरे शब्दों में कहें, तो पिरामिड पर आप जितना ऊपर चढ़ेंगे, आपको उतना ही आत्मविश्वास महसूस होगा. लेकिन रुकिए, पिरामिड क्या है?
टेस्ट की रणनीतियां तय करना: टेस्टिंग की रणनीति कैसे चुनें
सबसे पहले, यह तय करें कि ज़रूरी शर्तें पूरी करने के लिए, आपको किन हिस्सों की जांच करनी होगी. पता लगाएं कि किस तरह के टेस्ट टाइप का इस्तेमाल करना चाहिए और कितनी बारीकियों के आधार पर, लागत के किफ़ायती स्ट्रक्चर को बनाए रखते हुए सबसे ज़्यादा भरोसा हासिल किया जा सकता है. कई डेवलपर एनालॉग का इस्तेमाल करके इस विषय पर काम करते हैं. मशहूर क्लासिक से शुरू होने वाले सबसे सामान्य उदाहरण यहां दिए गए हैं.
क्लासिक: द टेस्ट पिरामिड
टेस्ट की रणनीतियां तय करने पर, शायद आपको सबसे पहले टेस्ट ऑटोमेशन पिरामिड के बारे में पता चले. माइक कॉन ने इस अवधारणा की शुरुआत अपनी किताब "सुसिडिंग विद एजाइल" में की थी. बाद में, मार्टिन फ़ॉलर ने अपने प्रैक्टिकल टेस्ट पिरामिड लेख में बताए गए सिद्धांत के बारे में विस्तार से बताया. पिरामिड को इस तरह से दिखाया जा सकता है:
जैसा कि इस ड्रॉइंग में दिखाया गया है, टेस्ट पिरामिड में तीन लेयर हैं:
Unit. आपको ये टेस्ट, पिरामिड की बेस लेयर पर दिखते हैं, क्योंकि इन्हें तुरंत चलाना और बनाए रखना आसान होता है. उन्हें अलग किया जाता है और सबसे छोटी जांच यूनिट को टारगेट किया जाता है. उदाहरण के लिए, बहुत छोटे प्रॉडक्ट के लिए सामान्य इकाई टेस्ट देखें.
इंटिग्रेशन. ये टेस्ट पिरामिड के बीच में हैं, क्योंकि इनमें एक्ज़ीक्यूशन स्पीड है और ये आपको यूनिट टेस्ट की तुलना में उपयोगकर्ता के ज़्यादा करीब ले जाते हैं. एपीआई टेस्ट, इंटिग्रेशन टेस्ट का एक उदाहरण है. इस टाइप के तौर पर, कॉम्पोनेंट टेस्ट को भी कैटगरी में बांटा जा सकता है.
E2E टेस्ट (इन्हें यूज़र इंटरफ़ेस (यूआई) टेस्ट भी कहा जाता है). ये टेस्ट, किसी असल उपयोगकर्ता और उसके इंटरैक्शन को सिम्युलेट करते हैं. ऐसे टेस्ट को लागू होने में ज़्यादा समय लगता है. इसलिए, ये ज़्यादा महंगे होते हैं. ये पिरामिड सबसे ऊपर हैं.
आत्मविश्वास बनाम संसाधनों की तुलना
जैसा कि पहले संक्षेप में बताया गया है, लेयर का क्रम कोई इत्तिफ़ाक़ नहीं है. उनमें प्राथमिकताओं और उन पर होने वाली लागतों के बारे में बताया जाता है. इससे आपको साफ़ तौर पर पता चलता है कि आपको हर लेयर के लिए कितने टेस्ट लिखने चाहिए. आपने टेस्टिंग टाइप की परिभाषा में इसे पहले ही देख लिया है.
E2E टेस्ट, आपके उपयोगकर्ताओं के सबसे करीब होते हैं. इसलिए, इनसे आपको पूरा भरोसा होता है कि आपका ऐप्लिकेशन सही तरीके से काम कर रहा है. हालांकि, उनमें एक संपूर्ण ऐप्लिकेशन स्टैक और एक सिम्युलेटेड उपयोगकर्ता की आवश्यकता होती है, इसलिए ये सबसे महंगे भी हो सकते हैं. इसलिए, आत्मविश्वास उन संसाधनों के साथ सीधा मुकाबला है, जिनकी आपको टेस्ट लागू करने के लिए ज़रूरत है.
पिरामिड इस समस्या को हल करने की कोशिश करता है. इसके लिए, आपका फ़ोकस यूनिट टेस्ट पर ज़्यादा रहता है और E2E टेस्ट में शामिल केस को प्राथमिकता दी जाती है. उदाहरण के लिए, उपयोगकर्ता की सबसे अहम गतिविधियां या ऐसी जगहें जहां खराबियों का खतरा सबसे ज़्यादा है. जैसा कि मार्टिन फ़ॉलर ने ज़ोर दिया है, कॉन के पिरामिड में दो सबसे ज़रूरी बातें इस तरह हैं:
- अलग-अलग स्तर के टेस्ट लिखें.
- आपको जितना ज़्यादा हाई लेवल मिलेगा, आपके पास उतने ही कम टेस्ट होंगे.
पिरामिड विकसित हुआ है! टेस्ट पिरामिड के अनुकूलन
कई सालों से, पिरामिड के आस-पास चर्चा चल रही है. ऐसा लगता है कि पिरामिड टेस्टिंग की रणनीतियों को बढ़ा-चढ़ाकर पेश करता है. इसमें तरह-तरह की टेस्टिंग की सुविधा शामिल नहीं है और अब यह असल दुनिया के हर प्रोजेक्ट के हिसाब से नहीं है. इसलिए, यह जानकारी गुमराह कर सकती है. क्या पिरामिड आकार से गिर गया है? Guillermo Roach के पास इस बारे में कुछ राय है:
टेस्ट लिखें. बहुत ज़्यादा नहीं. ज़्यादातर इंटिग्रेशन.
गिलर्मो राउच की पेशकश
यह इस विषय पर सबसे ज़्यादा कही जाने वाली कोट में से एक है, तो चलिए इसे इसके बारे में जानते हैं:
- "टेस्ट लिखें". इससे न सिर्फ़ लोगों का भरोसा बढ़ता है, बल्कि इसके रखरखाव में लगने वाला समय भी बचता है.
- "बहुत ज़्यादा नहीं". 100% कवरेज हमेशा अच्छा नहीं होता, क्योंकि इसके बाद आपकी जांच को प्राथमिकता नहीं दी जाती है और बहुत ज़्यादा रखरखाव करना पड़ता है.
- "ज़्यादातर इंटिग्रेशन". यहां एक बार फिर इंटिग्रेशन की जांच करने पर ज़ोर दिया गया है: इनमें, कारोबार के लिहाज़ से सबसे ज़रूरी वैल्यू होती है. यह वैल्यू हर दिन के हिसाब से, आपको हर दिन के हिसाब से एक भरोसेमंद लेवल की जानकारी देती है. इससे, इंटिग्रेशन की प्रोसेस के लिए तय समय भी मिलता है.
इससे आपको टेस्टिंग पिरामिड के बारे में फिर से सोचना पड़ता है और अपना ध्यान इंटिग्रेशन टेस्टिंग पर ले जाना पड़ता है. पिछले कुछ सालों में, कई बदलावों के सुझाव दिए गए हैं. आइए, हम उनमें से सबसे आम बदलावों पर नज़र डालते हैं.
डायमंड टेस्ट करें
पहला अनुकूलन, यूनिट टेस्टिंग पर ज़्यादा ज़ोर नहीं देता, जैसा कि टेस्ट पिरामिड में देखा जा सकता है. मान लें कि आपको यूनिट टेस्ट पर 100% कवरेज मिल गया है. हालांकि, अगली बार रीफ़ैक्टर करने पर, आपको इनमें से कई यूनिट टेस्ट अपडेट करने होंगे. ऐसे में, हो सकता है कि आप इन्हें छोड़कर आगे बढ़ जाएं. इससे वे नष्ट हो जाते हैं.
इस वजह से, इंटिग्रेशन की जांच पर ज़्यादा फ़ोकस करने के साथ-साथ, यह आकार दिख सकता है:
एक पिरामिड, हीरे में बदल जाता है. आपको पिछली तीन लेयर देखने को मिलेंगी, लेकिन उनका साइज़ अलग होगा. साथ ही, यूनिट लेयर को कट किया गया है:
- Unit. जिस तरह से आपने उन्हें पहले परिभाषित किया था उसी तरह यूनिट टेस्ट लिखें. हालांकि, वे खराब हो जाते हैं और सिर्फ़ सबसे गंभीर मामलों को ही प्राथमिकता देते हैं और उन्हें कवर करते हैं.
- इंटिग्रेशन. इंटिग्रेशन की जांच, जो आपको पता हैं. इसके लिए, अलग-अलग यूनिट के कॉम्बिनेशन की जांच की जाती है.
- E2E. यह लेयर, टेस्ट पिरामिड की तरह ही यूज़र इंटरफ़ेस (यूआई) टेस्ट को हैंडल करता है. ध्यान रखें कि सबसे ज़रूरी टेस्ट केस के लिए, सिर्फ़ E2E टेस्ट ही लिखें.
शहद के छत्ते की जांच करना
Spotify का एक और रूप है, जो टेस्ट डायमंड के जैसा ही है. हालांकि, इसे माइक्रोसर्विस पर आधारित सॉफ़्टवेयर सिस्टम के लिए ज़्यादा खास बनाया गया है. टेस्टिंग मधुमक्खी माइक्रोसर्विस पर आधारित सॉफ़्टवेयर सिस्टम के लिए लिखी जाने वाली जांचों की संख्या, दायरे, और जांच की संख्या का एक और विज़ुअल तुलना है. अपने छोटे साइज़ की वजह से, माइक्रोसर्विस में सबसे अहम जटिलता, सेवा के अंदर ही नहीं, बल्कि इस बात पर होती है कि वह दूसरों के साथ कैसे इंटरैक्ट करती है. इसलिए, किसी माइक्रोसर्विस के लिए टेस्टिंग की रणनीति में मुख्य तौर पर इंटिग्रेशन की जांच पर फ़ोकस करना चाहिए.
यह आकार हमें मधुमक्खी के छत्ते की याद दिलाता है. इसलिए, इसका यह नाम पड़ा. इसमें ये लेयर होती हैं:
- इंटिग्रेट किए गए टेस्ट. Spotify के लेख में जे॰ B. रेन्सबर्गर का इस्तेमाल करके इस लेयर के बारे में बताएं: “ऐसा टेस्ट जो दूसरे सिस्टम के सही होने के आधार पर पास हो जाएगा या फ़ेल हो जाएगा.” ऐसे टेस्ट में बाहरी चीज़ें शामिल होती हैं जिन पर आपको ध्यान देना होगा. इसके उलट, आपका सिस्टम एक डिपेंडेंसी है, जो अन्य सिस्टम को तोड़ देती है. अन्य एनालॉग के लिए E2E टेस्ट की तरह, इन टेस्ट का इस्तेमाल सावधानी से करें, सिर्फ़ ज़रूरी मामलों में.
- इंटिग्रेशन टेस्ट. अन्य अनुकूलनों की तरह, आपको इस लेयर पर ध्यान देना चाहिए. इसमें ऐसी जांच शामिल होती हैं जो अलग-अलग तरीकों से आपकी सेवा के सही होने की पुष्टि करती हैं. हालांकि, यह जांच दूसरी सेवाओं के साथ भी की जाती है. इसका मतलब है कि टेस्ट में कुछ अन्य सिस्टम भी शामिल होंगे और इंटरैक्शन पॉइंट पर फ़ोकस किया जाएगा. उदाहरण के लिए, एपीआई टेस्ट.
- लागू करने से जुड़ी जानकारी की जांच. ये टेस्ट, यूनिट टेस्ट से मिलते-जुलते हैं. ये टेस्ट, कोड के उन हिस्सों पर फ़ोकस करते हैं जो स्वाभाविक रूप से अलग होते हैं और जिनकी अपनी अंदरूनी जटिलता होती है.
अगर आपको टेस्टिंग की इस रणनीति के बारे में ज़्यादा जानना है, तो मार्टिन फ़ॉलर का वह पोस्ट जिसमें टेस्ट पिरामिड की तुलना मधुमक्खी के छत्ते से की गई है और Spotify का मूल लेख देखें.
टेस्ट ट्रॉफ़ी
आपको इंटिग्रेशन की जांच पर बार-बार फ़ोकस किया जा सकता है. हालांकि, पिछले लेख में आपको एक अन्य तरह का पता चला था, लेकिन वह सिद्धांत के तौर पर टेस्ट नहीं किया गया है. हालांकि, टेस्टिंग की रणनीति बनाते समय, यह एक अहम पहलू है. अब तक देखे गए ज़्यादातर अनुकूलनों में और टेस्ट पिरामिड में स्टैटिक विश्लेषण मौजूद नहीं है. यह अलग-अलग तरह की टेस्टिंग ट्रॉफ़ी ही होती है, जिसमें इंटिग्रेशन टेस्ट पर ध्यान देते हुए स्टैटिक विश्लेषण को ध्यान में रखा जाता है. टेस्टिंग ट्रॉफ़ी, गिलेरमो रॉच के पिछले उद्धरण से बनाई गई थी और इसे केंट सी॰ डॉड्स:
टेस्टिंग ट्रॉफ़ी में, टेस्ट से मिलने वाली जानकारी को अलग तरीके से दिखाया जाता है. इसमें चार लेयर होती हैं:
- स्टैटिक विश्लेषण. इस तुलना में यह एक अहम भूमिका निभाता है. डीबग करने के बताए गए तरीके को अपनाकर, टाइपिंग की गलतियों, स्टाइल की गलतियों, और अन्य बग का पता लगाया जा सकता है.
- यूनिट टेस्ट. वे यह पक्का करते हैं कि आपकी सबसे छोटी यूनिट की सही तरीके से जांच की जाए, लेकिन टेस्टिंग ट्रॉफ़ी, उन्हें टेस्ट पिरामिड की तरह टेस्ट नहीं करेगी.
- इंटिग्रेशन. इसमें मुख्य तौर पर, इस रणनीति को लागू करने पर फ़ोकस किया गया है. ऐसा इसलिए, क्योंकि इसमें लागत और भरोसे के बीच बेहतर तरीके से संतुलन बनाया जाता है, जैसा कि दूसरे बदलावों के साथ किया जाता है.
- यूज़र इंटरफ़ेस (यूआई) टेस्ट. E2E और विज़ुअल टेस्ट के साथ-साथ, टेस्ट पिरामिड में अपनी भूमिका की तरह ही, ये टेस्टिंग ट्रॉफ़ी में सबसे ऊपर हैं.
टेस्टिंग ट्रॉफ़ी के बारे में और पढ़ने के लिए, केंट सी॰ की ब्लॉग पोस्ट इस विषय पर Dodds.
यूज़र इंटरफ़ेस (यूआई) पर आधारित कुछ और तरीके
ये सभी चीज़ें अच्छी और अच्छी हैं, लेकिन आपकी रणनीति को “पिरामिड”, “हनीकॉम्ब” या “डायमंड” जैसा भी कहा जाए, इसमें अब भी कुछ न कुछ कमी है. हालांकि, टेस्ट ऑटोमेशन की मदद से ऐसा किया जा सकता है, लेकिन ध्यान रखें कि मैन्युअल तौर पर टेस्ट करना अब भी ज़रूरी है. ऑटोमेटेड टेस्टिंग से सामान्य कामों में रुकावट आनी चाहिए और क्वालिटी अश्योरेंस इंजीनियर को ज़रूरी क्षेत्रों पर ध्यान देने की ज़रूरत नहीं पड़नी चाहिए. मैन्युअल तौर पर टेस्ट करने की सुविधा को बदलने के बजाय, ऑटोमेशन को इस तरह की प्रोसेस को पूरा करना चाहिए. क्या बेहतर नतीजों के लिए, मैन्युअल टेस्टिंग को ऑटोमेशन के साथ इंटिग्रेट करने का कोई तरीका है?
आइस कोन का परीक्षण और केकड़े का परीक्षण करना
टेस्टिंग पिरामिड के दो रूप हैं, जिनमें यूआई पर फ़ोकस करने वाले टेस्टिंग के तरीकों पर ज़्यादा फ़ोकस किया गया है. दोनों में बहुत ज़्यादा भरोसा है. हालांकि, टेस्ट एक्ज़ीक्यूशन की धीमी रफ़्तार की वजह से ये ज़्यादा महंगे होते हैं.
पहला टेस्ट आइस कोन, पिरामिड की तरह उलटा दिखता है. मैन्युअल तरीके से टेस्ट किए बिना, इसे टेस्ट पिज़्ज़ा भी कहा जाता है.
आइस कोन में, मैन्युअल या यूज़र इंटरफ़ेस (यूआई) टेस्टिंग पर ज़्यादा फ़ोकस किया गया है और यूनिट टेस्टिंग पर सबसे कम फ़ोकस किया गया है. यह अक्सर ऐसे प्रोजेक्ट में बदल जाता है जहां डेवलपर ने टेस्टिंग की रणनीति पर सिर्फ़ कुछ विचार करके काम शुरू किया हो. आइस कोड को पैटर्न के हिसाब से सही नहीं माना जाता, क्योंकि यह सही नहीं है. संसाधनों और मैन्युअल तरीके से किया जाने वाला काम महंगा है.
टेस्ट केकड़ा, टेस्ट आइस कोन की तरह होता है. हालांकि, इसमें E2E और विज़ुअल टेस्टिंग पर ज़्यादा ज़ोर दिया जाता है:
इस टेस्ट रणनीति में एक और पहलू शामिल है: यह पुष्टि करता है कि आपका ऐप्लिकेशन ठीक से काम कर रहा है और ठीक से काम कर रहा है. टेस्टिंग क्रैब, विज़ुअल टेस्टिंग की अहमियत को हाइलाइट करता है, जिसके बारे में पिछले लेख में बताया गया है. इंटिग्रेशन टेस्टिंग को कॉम्पोनेंट और एपीआई टेस्टिंग में बांटा जाता है और आगे चलकर बैकग्राउंड में भेजा जाता है. यहां यूनिट टेस्टिंग की भूमिका ज़्यादा अहम होती है. टेस्टिंग की रणनीति के बारे में ज़्यादा जानकारी, टेस्टिंग क्रैब पर बने इस लेख में मिल सकती है.
ज़्यादा महंगा होने के बावजूद, जांच करने की ये दोनों रणनीतियां अलग-अलग तरह से काम करती हैं: उदाहरण के लिए, ऐसे छोटे प्रोजेक्ट में जहां कम टेस्ट की ज़रूरत होती है या जिनमें कम जटिल चीज़ें शामिल करने की ज़रूरत होती है. इस मामले में, इंटिग्रेशन टेस्टिंग पर फ़ोकस करने वाली टेस्टिंग की पूरी रणनीति ओवर-इंजीनियर की जा सकती है.
हालांकि, जांच करने की ये दोनों रणनीतियां ज़्यादा महंगी होती हैं, लेकिन उनकी जगह ज़्यादा होती है. उदाहरण के लिए, वे छोटे प्रोजेक्ट में काम करते हैं जिनमें कम टेस्ट करने होते हैं. साथ ही, इनमें बहुत ज़्यादा जटिलता की ज़रूरत नहीं होती. इस मामले में, इंटिग्रेशन की जांच पर फ़ोकस करके, बड़े पैमाने पर टेस्टिंग की रणनीति को समझना मुश्किल हो सकता है.
काम की सलाह: चलिए रणनीति बनाते हैं!
अब आपने सबसे ज़्यादा इस्तेमाल होने वाली जांच की रणनीतियों के बारे में जान लिया है. आपने क्लासिक, टेस्ट पिरामिड - से शुरुआत की थी और इसके कई बदलावों के बारे में जाना है. अब आपको अपने प्रॉडक्ट के लिए उनकी जांच करनी है और तय करना है कि आपके प्रोजेक्ट के लिए इनमें से कौनसा प्रॉडक्ट सबसे अच्छा रहेगा. इस सवाल का जवाब सभी के पसंदीदा "यह निर्भर करता है" से शुरू होना चाहिए. हालांकि, यह इसे कम सटीक नहीं बनाता है.
आपके ऐप्लिकेशन के हिसाब से, सबसे सही रणनीति चुनने का विकल्प होता है. इनमें से वे रणनीति भी चुनी जा सकती है जो उपलब्ध नहीं हैं और उनमें से कौनसी रणनीति छोड़ दी गई है. इससे आपको अपने प्लैटफ़ॉर्म के डिज़ाइन, ज़रूरतों, और उपयोगकर्ताओं और उनकी ज़रूरतों के बारे में भी जानकारी मिलनी चाहिए. अलग-अलग ऐप्लिकेशन के लिए, ये सभी बातें अलग हो सकती हैं. यह पूरी तरह सामान्य है. याद रखें कि आपका सबसे ज़रूरी लक्ष्य अपने उपयोगकर्ताओं को सेवा देना है, न कि टेक्स्टबुक की परिभाषा.
अक्सर, वास्तविक दुनिया में किए जाने वाले परीक्षणों को अलग-अलग करना और अलग-अलग परिभाषित करना मुश्किल होता है. यहां तक कि मार्टिन फ़ॉलर खुद भी अलग-अलग परिभाषाओं के सकारात्मक पहलू पर ज़ोर देते हैं, जैसा कि यूनिट टेस्ट के मामले में होता है. जैसा कि जस्टिन सर्ल्स अपने ट्वीट में सही कहते हैं:
[...] ऐसे टेस्ट लिखें जो साफ़ तौर पर सीमाएं तय करें, तेज़ी से और सही तरीके से चलते हों, और सिर्फ़ काम की वजहों से फ़ेल हों.
जस्टिन सर्ल्स का लिखा हुआ
उन जांचों पर ध्यान दें जो उपयोगकर्ताओं को हो सकने वाली असल गड़बड़ियों की जानकारी देती हैं. ऐसा न करें कि आपका लक्ष्य पूरा न हो. टेस्ट को उपयोगकर्ता के फ़ायदे के लिए डिज़ाइन किया जाना चाहिए, न कि सिर्फ़ 100% कवरेज देने या इस बात पर बहस करने के लिए कि कितना प्रतिशत टेस्ट लिखना है.
उन टेस्ट पर ध्यान दें जो असल ज़िंदगी की गड़बड़ियों की जानकारी देते हैं. ये गड़बड़ियां आपके उपयोगकर्ताओं को हो सकती हैं और उनका ध्यान आपके लक्ष्य से हटता नहीं है. टेस्ट को उपयोगकर्ता को फ़ायदा पहुंचाने के लिए डिज़ाइन किया जाना चाहिए, न कि सिर्फ़ 100% कवरेज देने या इस बात पर बहस शुरू करने वाली होनी चाहिए कि आपको किसी खास टेस्टिंग टाइप का कितना प्रतिशत हिस्सा लिखना चाहिए.