यदि हम एक फ़ंक्शन B का परीक्षण करके, फ़ंक्शन C का परीक्षण करते हैं, जो फ़ंक्शन B को कॉल करता है, अर्थात फ़ंक्शन C का परीक्षण करने के लिए एक परीक्षण प्रोग्राम लिख रहा है, जो कि फ़ंक्शन B को कॉल करता है, तो क्या परीक्षण विधि अभी भी इकाई परीक्षण, या कुछ और है?
जब किसी फ़ंक्शन पर अप्रत्यक्ष रूप से परीक्षण करना पसंद किया जाता है जो लक्ष्य फ़ंक्शन को कॉल करता है, और सीधे फ़ंक्शन का परीक्षण करना कब पसंद किया जाता है?
जवाबों:
यूनिट टेस्ट की एक लोकप्रिय परिभाषा ISTQB है:
एक इकाई परीक्षण कार्यों, कक्षाओं, प्रक्रियाओं, इंटरफेस जैसे किसी एप्लिकेशन का सबसे छोटा परीक्षण योग्य हिस्सा है। यूनिट परीक्षण एक ऐसी विधि है जिसके द्वारा स्रोत कोड की व्यक्तिगत इकाइयों को यह निर्धारित करने के लिए परीक्षण किया जाता है कि क्या वे उपयोग के लिए फिट हैं।
इस परिभाषा के अनुसार:
अब इरादे और परीक्षण के दायरे में अंतर हो सकता है। यदि आप C का उपयोग करके B के लिए एक परीक्षण कार्यक्रम लिखते हैं, तो यह अभी भी C का एक इकाई परीक्षण है, क्योंकि आप सभी कर सकते हैं कि C को इनपुट प्रदान करना है और यदि B सही था, तो आउटपुट के आधार पर जांच करें। यह सिर्फ इतना है कि आप बी काम करते हैं क्योंकि सी काम करता है।
एकीकरण परीक्षण की एक परिभाषा यह भी है :
इंटरफेस में और एकीकृत घटकों या प्रणालियों के बीच बातचीत में दोषों को उजागर करने के लिए परीक्षण किया गया।
सॉफ़्टवेयर घटकों की सामान्य परिभाषा का अर्थ है कि यह स्वतंत्र है और इसे अपने दम पर तैनात किया जा सकता है। यहां, बी और सी स्वतंत्र घटक नहीं लगते हैं, इसलिए हमारे पास कोई एकीकरण परीक्षण नहीं है।
यह बहुत कुछ इस बात पर निर्भर करता है कि आप एक इकाई को क्या मानते हैं। यदि Cइतना सरल है कि अलग से परीक्षण करने का कोई मतलब नहीं है, तो आपका परीक्षण एक इकाई परीक्षण है।
किसी विशेष इकाई के 100% लाइन कवरेज के करीब होने के लिए, और सभी व्यावहारिक रूप से प्रत्याशित कोड रास्तों का परीक्षण करने के लिए आपके सूट के लिए बहुत अधिक महत्वपूर्ण है ।
यदि कार्य अन्य कार्यों को कहते हैं, तो हाँ, हम इसे अभी भी एक इकाई-परीक्षण कहते हैं।
यूनिट-परीक्षणों को एक वर्ग के सार्वजनिक व्यवहार का परीक्षण करना चाहिए, न कि निजी कार्यान्वयन। जैसा कि इस टॉयलेट लेख पर Google के परीक्षण द्वारा सुझाया गया है ।
यदि आप क्लीन कोड के नियमों का पालन करते हैं तो आपके कार्य लंबे नहीं होने चाहिए तो कोड की 4 लाइनें। यह आपके यूनिट-परीक्षणों के साथ एक और निजी फ़ंक्शन का परीक्षण नहीं करना असंभव बनाता है।
आपको अधिकांश निजी कार्यों को अलग से क्यों नहीं करना चाहिए? क्योंकि रिफैक्टरिंग आपको अपने सभी कार्यान्वयन इकाई-परीक्षणों को अद्यतन रखने के लिए मजबूर करेगा। जब आप उनमें से बहुत कुछ करते हैं, तो यह निराशाजनक हो जाएगा, जबकि सार्वजनिक व्यवहार को फिर से तैयार करने के दौरान नहीं बदलना चाहिए और इस प्रकार परीक्षण को किसी भी अद्यतन की आवश्यकता नहीं होनी चाहिए। आपको अपने सार्वजनिक माता-पिता के साथ निजीकरण का परीक्षण करने में सक्षम होना चाहिए। कभी-कभी यह जटिल निजीकरण के परीक्षण के लायक हो सकता है, लेकिन आश्चर्य है कि क्या वे अपने दम पर एक अलग वर्ग होना चाहिए?
एकीकरण परीक्षण :
अब यदि फ़ंक्शन किसी अन्य वर्ग का हिस्सा है तो यह अलग है। तब हम इसे घटक परीक्षण या एकीकरण परीक्षण कहेंगे। आप कई वर्गों को एकीकृत कर रहे हैं और उनके खिलाफ एक परीक्षण चला रहे हैं। फंक्शन बी फंक्शन सी पर निर्भर करेगा। यूनिट-टेस्ट में सक्षम होने के लिए फंक्शन बी का उपयोग आप अपने परीक्षण कर रहे फ़ंक्शन को अलग करने के लिए निर्भरता इंजेक्शन का उपयोग कर सकते हैं, अब यह फिर से एक यूनिट-टेस्ट होगा।