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