जगह में सभी निर्भरता के साथ परीक्षण अभी भी महत्वपूर्ण है, लेकिन जेफरी फॉस्ट ने कहा कि यह एकीकरण परीक्षण के दायरे में अधिक है।
इकाई परीक्षण का सबसे महत्वपूर्ण पहलू आपके परीक्षणों को विश्वसनीय बनाना है। यदि आपको भरोसा नहीं है कि वास्तव में उत्तीर्ण परीक्षा का अर्थ है कि चीजें अच्छी हैं और असफल परीक्षा का वास्तव में उत्पादन कोड में कोई समस्या है, तो आपके परीक्षण लगभग उतने उपयोगी नहीं हैं जितने कि वे हो सकते हैं।
अपने परीक्षणों को विश्वसनीय बनाने के लिए, आपको कुछ चीजें करनी होंगी, लेकिन मैं इस उत्तर के लिए सिर्फ एक पर ध्यान केंद्रित करने जा रहा हूं। आपको यह सुनिश्चित करना होगा कि वे चलाना आसान है, ताकि सभी डेवलपर कोड चेक करने से पहले उन्हें आसानी से चला सकें। "चलाने में आसान" का अर्थ है कि आपके परीक्षण तेज़ी से चलते हैं और उन्हें बनाने के लिए कोई व्यापक कॉन्फ़िगरेशन या सेटअप की आवश्यकता नहीं है। आदर्श रूप से, किसी को भी कोड के नवीनतम संस्करण की जांच करने में सक्षम होना चाहिए, तुरंत परीक्षण चलाएं और उन्हें पास करें।
अन्य चीजों (फ़ाइल सिस्टम, डेटाबेस, वेब सेवाओं, आदि) पर निर्भरता को दूर करना आपको कॉन्फ़िगरेशन की आवश्यकता से बचने में सक्षम बनाता है और आपको और अन्य डेवलपर्स को उन स्थितियों के लिए कम संवेदनशील बनाता है जहां आपको यह कहने की परीक्षा होती है कि "ओह, परीक्षण विफल रहे क्योंकि मैं डॉन ' t के पास नेटवर्क शेयर सेट अप है। ओह, मैं उन्हें बाद में चलाऊंगा। "
यदि आप कुछ डेटा के साथ परीक्षण करना चाहते हैं, तो उस व्यावसायिक तर्क कोड के लिए आपकी इकाई परीक्षण आपको इस बात की परवाह नहीं करनी चाहिए कि आपको वह डेटा कैसे मिलता है। डेटाबेस जैसी सहायक सामग्री के आधार पर आपके एप्लिकेशन के मुख्य तर्क का परीक्षण करने में सक्षम होना भयानक है। यदि आप ऐसा नहीं कर रहे हैं, तो आप गायब हैं।
पीएस मुझे यह जोड़ना चाहिए कि टेस्टेबिलिटी के नाम पर निश्चित रूप से यह अधिक संभव है। आपके एप्लिकेशन का परीक्षण करने से उसे कम करने में मदद मिलती है। लेकिन किसी भी घटना में, एक दृष्टिकोण के खराब कार्यान्वयन दृष्टिकोण को कम वैध नहीं बनाते हैं। किसी भी चीज का गलत इस्तेमाल किया जा सकता है और अगर कोई यह नहीं पूछता कि "मैं ऐसा क्यों कर रहा हूं?" विकास करते समय।
जहां तक आंतरिक निर्भरता का सवाल है, चीजें थोड़ी मैला हो जाती हैं। जिस तरह से मैं इसके बारे में सोचना पसंद करता हूं वह यह है कि मैं अपनी कक्षा को गलत कारणों से बदलने से यथासंभव बचाना चाहता हूं। अगर मेरे पास कुछ इस तरह से एक सेटअप है ...
public class MyClass
{
private SomeClass someClass;
public MyClass()
{
someClass = new SomeClass();
}
// use someClass in some way
}
मुझे आमतौर पर परवाह नहीं है कि कैसे SomeClassबनाया जाता है। मैं सिर्फ इसका इस्तेमाल करना चाहता हूं। अगर SomeClass बदलता है और अब कंस्ट्रक्टर को पैरामीटर की आवश्यकता होती है ... तो यह मेरी समस्या नहीं है। मुझे इसे समायोजित करने के लिए MyClass को बदलना नहीं चाहिए।
अब, यह केवल डिज़ाइन भाग पर स्पर्श कर रहा है। जहां तक यूनिट परीक्षणों का सवाल है, मैं खुद को अन्य वर्गों से बचाना चाहता हूं। यदि मैं MyClass का परीक्षण कर रहा हूं, तो मुझे इस तथ्य के लिए जानना पसंद है कि कोई बाहरी निर्भरता नहीं है, कि SomeClass ने किसी बिंदु पर डेटाबेस कनेक्शन या किसी अन्य बाहरी लिंक को प्रस्तुत नहीं किया है।
लेकिन इससे भी बड़ा मुद्दा यह है कि मुझे यह भी पता है कि मेरे कुछ तरीकों के परिणाम SomeClass पर कुछ विधि से आउटपुट पर निर्भर करते हैं। कुछ क्लॉक को मॉकिंग / स्टबिंग के बिना, मेरे पास उस इनपुट को मांग में भिन्न करने का कोई तरीका नहीं हो सकता है। अगर मैं भाग्यशाली हूं, तो मैं इस तरह से परीक्षण के अंदर अपने वातावरण को बनाने में सक्षम हो सकता हूं कि यह SomeClass से सही प्रतिक्रिया को ट्रिगर करेगा, लेकिन इस तरह से जाना मेरे परीक्षणों में जटिलता का परिचय देता है और उन्हें भंगुर बनाता है।
निर्माण में SomeClass के एक उदाहरण को स्वीकार करने के लिए MyClass को फिर से लिखना मुझे SomeClass का एक नकली उदाहरण बनाने में सक्षम बनाता है जो मुझे वांछित मूल्य देता है (या तो मॉकिंग फ्रेमवर्क के माध्यम से या मैनुअल मॉक के साथ)। मुझे आम तौर पर इस मामले में एक इंटरफ़ेस शुरू करने की ज़रूरत नहीं है । ऐसा करना या न करना कई मायनों में एक व्यक्तिगत पसंद है जिसे आपकी पसंद की भाषा द्वारा निर्धारित किया जा सकता है (जैसे इंटरफेस सी # में अधिक होने की संभावना है, लेकिन आपको निश्चित रूप से रूबी में एक की आवश्यकता नहीं होगी)।