हम सभी जानते हैं कि हमें इकाई परीक्षण और एकीकरण परीक्षण लिखना चाहिए लेकिन यह कभी-कभी स्पष्ट नहीं होता है कि क्यों। बहुत बार हमें ऐसी परियोजनाएँ मिलती हैं, जहाँ दोनों के बीच चिंता का अलगाव स्पष्ट रूप से परिभाषित नहीं होता है, जहाँ कुछ स्कोपों ​​को एक से अधिक परीक्षणों द्वारा कवर किया जाता है, जबकि अन्य स्कोपों ​​को ठीक से कवर नहीं किया जाता है।

उदाहरण

आइए निम्नलिखित एप्लिकेशन पर विचार करें जो उपयोगकर्ता को बुरे तरीके से दुनिया भर में ले जाने देता है:

मीडिया को नियंत्रण में करके, दुष्ट प्रौद्योगिकी विकास को गति देने वाला एक धागा चलाना और अंत में एक डायस्टोपियन भविष्य स्थापित करना:

दुनिया हावी दिखाई देगी:

हमें यूनिट परीक्षणों का उपयोग करके इस व्यवहार का परीक्षण करना चाहिए। यूनिट परीक्षणों को प्रत्येक घटक को अपने आप पर परीक्षण करना चाहिए। यह सुनिश्चित करने के लिए कि हम केवल उस घटक और उसके किसी भी निर्भरता का परीक्षण नहीं करते हैं, हम मोक्स का उपयोग करते हैं।

उदाहरण के लिए, यहाँ हमारी सेवा के लिए परीक्षा है:

और यहाँ हमारे नियंत्रक के लिए एक है:

और जैसा कि हम जानते हैं, हमारे एकीकरण परीक्षण का परीक्षण करना चाहिए कि विभिन्न घटक एक दूसरे के साथ कैसे खेलते हैं, और इसमें हमारा स्प्रिंग संदर्भ भी शामिल है। हम इसे ब्लैकबॉक्स रखना चाहते हैं, इसलिए हमें बस अपने नियंत्रक को कॉल करना चाहिए और परिणाम को सत्यापित करना चाहिए जैसा कि हम उम्मीद करते हैं (हमारी दुनिया पर हावी है) :

अब क्या होगा अगर हम अपने विश्व प्रभुत्व की खोज में इतनी बुराई न करने का फैसला करें? क्या होगा अगर हम मुक्त मीडिया की अनुमति देने का निर्णय लेते हैं, अद्भुत अच्छी तकनीक और उज्ज्वल भविष्य आखिर है क्या?

दूसरे शब्दों में, यदि हम एक और कार्यान्वयन का चयन करने का निर्णय लेते हैं, तो क्या होगा ?

अब हमने नई कार्यक्षमता जोड़ी जो इकाई परीक्षणों का उपयोग करके जांच की जानी चाहिए:

लेकिन हम कैसे जानते हैं कि हमारे अंतर्निहित कार्यान्वयन को बदलकर, हम अभी भी वांछित परिणाम प्राप्त कर रहे हैं? ध्यान दें कि जब हमारी यूनिट के परीक्षण बदले गए, तो हमारा एकीकरण परीक्षण नहीं हुआ:

अब हमें बस इसे फिर से चलाने की जरूरत है और हम जानते हैं कि हमारा आवेदन अभी भी उसी तरह काम करता है जैसे:

बिंदु

एक अच्छी तरह से डिज़ाइन किया गया एकीकरण परीक्षण हमें आसानी से दावा करने में सक्षम होना चाहिए कि परीक्षण किए जा रहे दायरे के अंतर्निहित कार्यान्वयन को बदलने से वांछित परिणाम नहीं बदलता है।

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

परियोजना संरचना के बारे में एक शब्द

चूंकि यूनिट परीक्षण हमारे मुख्य फ़ोल्डर में प्रत्येक घटक को कवर करना चाहिए, परीक्षण फ़ोल्डर की संरचना को प्रतिबिंबित करना चाहिए:

लेकिन एकीकरण परीक्षणों के बारे में क्या? वे कहां फिट होते हैं? इसे संभालने का एक तरीका उन्हें एक अलग स्रोत निर्देशिका में रखना है:

इसे आसानी से मावेन में कॉन्फ़िगर किया जा सकता है:

मावेन, इस तरह से यूनिट परीक्षणों और एकीकरण परीक्षणों के बीच डिफ़ॉल्ट रूप से अंतर करता है, लेकिन यह केवल उन्हें अलग-अलग नाम देने के लिए पर्याप्त है (क्रमशः टेस्ट और * आईटी, जो हम यहां किसी भी मामले में करते हैं)। विभिन्न निर्देशिकाएं संगठन के संदर्भ में आगे हमारी मदद करती हैं।

उम्मीद है की यह मदद करेगा :)

यहां प्रोजेक्ट देखें