unit testing एकीकरण और इकाई परीक्षण के बीच क्या अंतर है?




यूनिट टेस्ट इन हिंदी (16)

मैं इकाई परीक्षण और एकीकरण परीक्षण की तथाकथित पाठ्यपुस्तक परिभाषा जानता हूं। मैं इस बारे में उत्सुक हूं कि यूनिट परीक्षण लिखने का समय कब है ... मैं उन्हें यथासंभव कक्षाओं के कई सेटों को कवर करने के लिए लिखूंगा।

उदाहरण के लिए, यदि मेरे पास Word क्लास है, तो मैं Word क्लास के लिए कुछ यूनिट टेस्ट लिखूंगा। फिर, मैं अपनी Sentence वर्ग लिखना शुरू करता हूं, और जब इसे Word क्लास के साथ बातचीत करने की आवश्यकता होती है, तो मैं अक्सर अपने यूनिट परीक्षण लिखता हूं जैसे कि वे Sentence और Word दोनों का परीक्षण करते हैं ... कम से कम उन स्थानों पर जहां वे बातचीत करते हैं।

क्या ये परीक्षण अनिवार्य रूप से एकीकरण परीक्षण बन गए हैं क्योंकि अब वे इन 2 वर्गों के एकीकरण का परीक्षण करते हैं, या यह सिर्फ एक यूनिट परीक्षण है जो 2 वर्गों को फैलाता है?

आम तौर पर, इस अनिश्चित रेखा के कारण, मैं शायद ही कभी एकीकरण परीक्षण लिखूंगा ... या मेरा पूरा उत्पाद उपयोग कर रहा है यह देखने के लिए कि क्या सभी टुकड़े सही एकीकरण परीक्षण सही तरीके से काम करते हैं, भले ही वे मैन्युअल हैं और शायद ही कभी दायरे से परे दोहराए गए हों प्रत्येक व्यक्तिगत सुविधा का?

क्या मैं एकीकरण परीक्षणों को गलत समझ रहा हूं, या क्या वास्तव में एकीकरण और इकाई परीक्षणों के बीच बहुत ही कम अंतर है?

संपादित करें

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


यूनिट परीक्षण: एक इकाई या सॉफ्टवेयर के सबसे छोटे टुकड़े के लिए किया गया परीक्षण। यह सत्यापित करने के लिए किया गया है कि क्या यह इसके कार्यात्मक विनिर्देश या इसकी इच्छित डिजाइन संरचना को संतुष्ट करता है।

एकीकरण परीक्षण: संबंधित संयुक्त मॉड्यूल को संयुक्त कार्यक्षमता के लिए एकसाथ परीक्षण करना।


एकल जिम्मेदारी डिजाइन का उपयोग, इसका काला और सफेद। 1 से अधिक ज़िम्मेदारी, यह एक एकीकरण परीक्षण है।

बतख परीक्षण (दिखता है, quacks, waddles, यह एक बतख) द्वारा, यह सिर्फ एक इकाई परीक्षण में 1 से अधिक नई वस्तु के साथ।

जब आप एमवीसी में प्रवेश करते हैं और इसका परीक्षण करते हैं, तो नियंत्रक परीक्षण हमेशा एकीकरण होते हैं, क्योंकि नियंत्रक में एक मॉडल इकाई और दृश्य इकाई दोनों होती है। उस मॉडल में परीक्षण तर्क, मैं एक यूनिट परीक्षण बुलाऊंगा।


निम्नलिखित शर्तों में अपने परीक्षण की प्रकृति के बारे में सोचें:

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

याद रखें कि एकीकरण परीक्षण अभी भी अपनी कुछ निर्भरताओं को दूर / नकली / नकली कर सकता है। यह यूनिट परीक्षण और सिस्टम परीक्षण (सबसे व्यापक एकीकरण परीक्षण, सभी सिस्टम का परीक्षण) के बीच बहुत अधिक मध्य ग्राउंड प्रदान करता है।

तो एक व्यावहारिक दृष्टिकोण होगा: लचीला रूप से एकीकरण परीक्षणों पर भरोसा करें जितना आप समझदारी से कर सकते हैं और इकाई परीक्षणों का उपयोग करें जहां यह बहुत जोखिम भरा या असुविधाजनक होगा। इस तरह की सोच इकाई परीक्षणों और एकीकरण परीक्षणों के कुछ विडंबनात्मक भेदभाव से अधिक उपयोगी हो सकती है।


मुझे लगता है कि मैं अभी भी एक इंटरैक्टिंग कक्षाओं को एक यूनिट टेस्ट कहूंगा, बशर्ते कक्षा 1 के लिए यूनिट परीक्षण कक्षा 1 की सुविधाओं का परीक्षण कर रहे हों, और कक्षा 2 के लिए यूनिट परीक्षण इसकी विशेषताओं का परीक्षण कर रहे हैं, और यह भी कि वे डेटाबेस को मार नहीं रहे हैं।

जब मैं अपने अधिकांश ढेर के माध्यम से चलता हूं और डेटाबेस को भी हिट करता हूं तो मैं एक परीक्षण परीक्षण को कॉल करता हूं।

मुझे वास्तव में यह सवाल पसंद है, क्योंकि टीडीडी चर्चा कभी-कभी मुझे थोड़ा सा शुद्ध महसूस करती है, और मेरे लिए कुछ ठोस उदाहरण देखने के लिए अच्छा है।


एकीकरण परीक्षण: डेटाबेस दृढ़ता का परीक्षण किया जाता है।
यूनिट परीक्षण: डेटाबेस पहुंच मजाक कर दी गई है। कोड विधियों का परीक्षण किया जाता है।


मेरी राय में जवाब है "यह क्यों मायने रखता है?"

क्या ऐसा इसलिए है क्योंकि इकाई परीक्षण कुछ ऐसा करते हैं जो आप करते हैं और एकीकरण परीक्षण कुछ ऐसा नहीं है जो आप नहीं करते हैं? या ठीक इसके विपरीत? बेशक नहीं, आपको दोनों को करने की कोशिश करनी चाहिए।

क्या ऐसा इसलिए है क्योंकि यूनिट परीक्षणों को तेज़, पृथक, दोहराने योग्य, स्व-मान्य करने और समय पर और एकीकरण परीक्षणों की आवश्यकता नहीं है? बेशक नहीं, सभी परीक्षण इन होना चाहिए।

ऐसा इसलिए है क्योंकि आप यूनिट परीक्षणों में मोक्स का उपयोग करते हैं लेकिन आप उन्हें एकीकरण परीक्षणों में उपयोग नहीं करते हैं? बिलकूल नही। इसका मतलब यह होगा कि अगर मेरे पास एक उपयोगी एकीकरण परीक्षण है तो मुझे किसी हिस्से के लिए नकली जोड़ने की अनुमति नहीं है, डर मुझे अपने परीक्षण का नाम "यूनिट टेस्ट" में बदलना होगा या इसे काम करने के लिए इसे दूसरे प्रोग्रामर को सौंपना होगा।

क्या ऐसा इसलिए है क्योंकि इकाई परीक्षण एक इकाई का परीक्षण करता है और एकीकरण परीक्षण कई इकाइयों का परीक्षण करता है? बिलकूल नही। क्या व्यावहारिक महत्व है? परीक्षणों के दायरे पर सैद्धांतिक चर्चा अभ्यास में टूट जाती है क्योंकि "इकाई" शब्द पूरी तरह से संदर्भ निर्भर है। कक्षा के स्तर पर, एक इकाई एक विधि हो सकती है। एक असेंबली स्तर पर, एक इकाई एक वर्ग हो सकती है, और सेवा स्तर पर, एक इकाई एक घटक हो सकती है। और यहां तक ​​कि कक्षाएं अन्य वर्गों का भी उपयोग करती हैं, तो इकाई कौन सा है?

यह कोई महत्व नहीं है।

परीक्षण महत्वपूर्ण है, पहला महत्वपूर्ण है, परिभाषाओं के बारे में विभाजित बाल समय की बर्बादी है जो केवल नए आने वालों को परीक्षण करने में भ्रमित करता है।


जब मैं यूनिट परीक्षण लिखता हूं, तो उस कक्षा में परीक्षण किए जा रहे कोड के दायरे को सीमित करता हूं जिसे मैं वर्तमान में निर्भरताओं का मज़ाक उड़ाकर लिख रहा हूं। अगर मैं एक वाक्य वर्ग लिख रहा हूं, और वाक्य की वर्ड पर निर्भरता है, तो मैं एक नकली शब्द का उपयोग करूंगा। वर्ड का मज़ाक उड़ाकर मैं केवल अपने इंटरफ़ेस पर ध्यान केंद्रित कर सकता हूं और मेरी वाक्य कक्षा के विभिन्न व्यवहारों का परीक्षण कर सकता हूं क्योंकि यह वर्ड इंटरफ़ेस के साथ इंटरैक्ट करता है। इस तरह मैं केवल वाक्य के व्यवहार और कार्यान्वयन का परीक्षण कर रहा हूं और साथ ही साथ Word के कार्यान्वयन का परीक्षण नहीं कर रहा हूं।

एक बार जब मैंने यूनिट परीक्षणों को लिखा है, यह सुनिश्चित करने के लिए कि जब वाक्य वर्ड इंटरफेस के आधार पर शब्द के साथ इंटरैक्ट करता है तो वाक्य सही ढंग से व्यवहार करता है, तो मैं यह सुनिश्चित करने के लिए एकीकरण परीक्षण लिखता हूं कि बातचीत के बारे में मेरी धारणाएं सही थीं। इसके लिए मैं वास्तविक वस्तुओं की आपूर्ति करता हूं और एक परीक्षा लिखता हूं जो एक ऐसी सुविधा का उपयोग करता है जो वाक्य और शब्द दोनों का उपयोग कर समाप्त हो जाएगा।


उपरोक्त उदाहरण बहुत अच्छे हैं और मुझे उन्हें दोहराने की आवश्यकता नहीं है। इसलिए मैं समझने में आपकी सहायता के लिए उदाहरणों का उपयोग करने पर ध्यान केंद्रित करूंगा।

एकीकरण टेस्ट

एकीकरण परीक्षण जांचें कि क्या सब कुछ एक साथ काम कर रहा है। एक घड़ी में एक साथ काम कर रहे कोग की एक श्रृंखला की कल्पना करो। एकीकरण परीक्षण होगा: घड़ी सही समय बता रही है? क्या यह अभी भी 3 दिनों में सही समय बता रहा है?

यह सब आपको बताता है कि क्या समग्र टुकड़ा काम कर रहा है या नहीं। यदि यह विफल रहता है: यह आपको बिल्कुल नहीं बताता है कि यह कहां विफल हो रहा है।

यूनिट टेस्ट

ये वास्तव में विशिष्ट प्रकार के परीक्षण हैं। वे आपको बताते हैं कि एक विशिष्ट चीज काम कर रही है या असफल रही है। इस प्रकार के परीक्षण की कुंजी यह है कि यह मानते हुए कि यह सब ठीक काम कर रहा है, यह केवल एक विशिष्ट चीज का परीक्षण करता है। यह महत्वपूर्ण बात है।

उदाहरण: उदाहरण के लिए इस बिंदु पर विस्तार से बताएं:

  • चलिए एक उदाहरण के रूप में एक कार लेते हैं।
  • एक कार के लिए एकीकरण परीक्षण: उदाहरण के लिए कार इचुका और वापस चला जाता है। यदि ऐसा होता है, तो आप सुरक्षित रूप से कह सकते हैं कि एक कार एक समग्र दृश्य बिंदु से काम कर रही है। यह एक एकीकरण परीक्षण है। यदि यह विफल रहता है तो आपको पता नहीं है कि यह वास्तव में असफल रहा है: क्या यह रेडिएटर, ट्रांसमिशन, इंजन या कार्बोरेटर है? तुम्हें कुछ पता नहीं है। यह कुछ भी हो सकता है।
  • एक कार के लिए यूनिट परीक्षण : इंजन काम कर रहा है। यह परीक्षण मानता है कि कार में बाकी सब कुछ ठीक काम कर रहा है। इस तरह यदि यह विशेष इकाई परीक्षण विफल रहता है: आप बहुत आश्वस्त हो सकते हैं कि समस्या इंजन में निहित है - ताकि आप समस्या को जल्दी से अलग कर सकें और ठीक कर सकें।

आपके एकीकरण और इकाई परीक्षणों को मिलाकर परिणाम:

  • मान लीजिए कि आपकी कार एकीकरण परीक्षण विफल रहता है। यह इचुका को सफलतापूर्वक ड्राइव नहीं करता है। समस्या कहाँ हे?

  • आप अपने इंजन परीक्षण में देखते हैं। लेकिन इस विशेष मामले में, इंजन परीक्षण बाह्य निर्भरताओं का उपयोग करता है: यह एक विशेष ईंधन प्रणाली का उपयोग करता है। मान लीजिए कि इंजन इकाई परीक्षण भी असफल रहा है। दूसरे शब्दों में, एकीकरण परीक्षण और इंजन इकाई परीक्षण दोनों विफल हो गए हैं। फिर समस्या कहाँ है? (उत्तर पाने के लिए खुद को 10 सेकंड दें।) • क्या इंजन असफल रहा, या क्या यह ईंधन प्रणाली थी जिससे इंजन विफल हो गया?

आप यहाँ समस्या देखते हैं? आप नहीं जानते कि वास्तव में क्या असफल रहा है। यदि आप 10 निर्भरताओं का उपयोग करते हैं, तो उन 10 में से प्रत्येक एक समस्या का कारण बन सकता है - और आपको नहीं पता कि कहां से शुरू करना है। यही कारण है कि यूनिट परीक्षण करने के लिए mocks परीक्षण करता है कि बाकी सब कुछ ठीक काम कर रहा है।

आशा है कि ये आपकी मदद करेगा।


यूनिट परीक्षण मैक्स का उपयोग करें

जिस चीज के बारे में आप बात कर रहे हैं वह एकीकरण परीक्षण है जो वास्तव में आपके सिस्टम के पूरे एकीकरण का परीक्षण करता है। लेकिन जब आप यूनिट परीक्षण करते हैं तो आपको वास्तव में प्रत्येक इकाई को अलग से जांचना चाहिए। बाकी सब कुछ मजाक किया जाना चाहिए। तो Sentence वर्ग के मामले में, यदि यह Word क्लास का उपयोग करता है, तो आपकी Word क्लास को मजाक किया जाना चाहिए। इस तरह, आप केवल अपनी Sentence वर्ग कार्यक्षमता का परीक्षण करेंगे।


मुझे लगता है कि जब आप एकीकरण परीक्षणों के बारे में सोचना शुरू करते हैं, तो आप तार्किक परतों के बजाय भौतिक परतों के बीच एक क्रॉस के बारे में अधिक बोल रहे हैं।

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

तकनीकी रूप से आप वैसे भी एक-कक्षा का यूनिट परीक्षण नहीं कर सकते हैं। क्या होगा यदि आपकी कक्षा कई अन्य वर्गों से बना है? क्या यह स्वचालित रूप से इसे एकीकरण परीक्षण बनाता है? मुझे ऐसा नहीं लगता।


क्या ये परीक्षण अनिवार्य रूप से एकीकरण परीक्षण बन गए हैं क्योंकि अब वे इन 2 वर्गों के एकीकरण का परीक्षण करते हैं? या यह सिर्फ एक यूनिट परीक्षण है जो 2 वर्गों को फैलाता है?

मुझे लगता है हाँ और हाँ। आपका यूनिट परीक्षण जो 2 वर्गों तक फैलता है वह एकीकरण परीक्षण बन गया।

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

वास्तविक अंतर का निष्पादन निम्नलिखित हो सकता है 1) 1,000,000 तत्वों का ऐरे आसानी से परीक्षण किया गया है और ठीक काम करता है। 2) बबलस्पोर्ट आसानी से इकाई के 10 तत्वों के नकली सरणी पर परीक्षण किया जाता है और यह भी ठीक काम करता है 3) एकीकरण परीक्षण से पता चलता है कि कुछ ठीक नहीं है।

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


मैं यूनिट को उन परीक्षणों का परीक्षण करता हूं जो सफेद बॉक्स एक कक्षा का परीक्षण करते हैं। वर्ग की आवश्यकता वाले किसी भी निर्भरता को नकली वाले (मॉक्स) के साथ प्रतिस्थापित किया जाता है।

एकीकरण परीक्षण वे परीक्षण होते हैं जहां एक ही समय में कई वर्ग और उनकी बातचीत का परीक्षण किया जाता है। इन मामलों में केवल कुछ निर्भरताएं फंसे / मजाक कर दी गई हैं।

मैं कंट्रोलर के एकीकरण परीक्षणों को तब तक नहीं बुलाऊंगा जब तक कि उनकी निर्भरता में से एक वास्तविक नहीं है (यानी फिक नहीं पड़ता) (उदाहरण के लिए IForms प्रमाणीकरण)।

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

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


मेरी 10 बिट्स: डी

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

एकीकरण टेस्ट अगला कदम है, यह एक या एक से अधिक घटकों को ले रहा है और यह सुनिश्चित कर रहा है कि वे एक साथ काम करें क्योंकि उन्हें चाहिए .. आप इस बात की जटिलताओं से ऊपर हैं कि घटक अलग-अलग कैसे काम करते हैं, लेकिन जब आप अपने एचटीएमएलएडिट नियंत्रण में एचटीएमएल दर्ज करते हैं, तो यह किसी भी तरह से जादुई जानता है कि यह वैध है या नहीं ..

हालांकि यह एक वास्तविक चलने योग्य रेखा है .. मैं बदले कोड को पूर्ण स्टॉप ^ _ ^ काम करने के लिए अधिक ध्यान केंद्रित करना चाहता हूं


यूनिट परीक्षण काम की एक इकाई या कोड के ब्लॉक के खिलाफ परीक्षण कर रहा है यदि आप चाहें तो। आमतौर पर एक डेवलपर द्वारा प्रदर्शन किया जाता है।

एकीकरण परीक्षण उस परीक्षण को संदर्भित करता है जो प्रदर्शन किया जाता है, अधिमानतः एकीकरण सर्वर पर, जब कोई डेवलपर अपने कोड को स्रोत नियंत्रण भंडार में करता है। एकीकरण परीक्षण क्रूज़ कंट्रोल जैसे उपयोगिताओं द्वारा किया जा सकता है।

तो आप यह सत्यापित करने के लिए अपना यूनिट परीक्षण करते हैं कि आपके द्वारा बनाए गए काम की इकाई काम कर रही है और फिर एकीकरण परीक्षण मान्य करता है कि जो भी आपने भंडार में जोड़ा है, वह कुछ और नहीं तोड़ दिया।


मैं वही करता हूं - मैं उन्हें सभी यूनिट परीक्षणों को बुलाता हूं, लेकिन किसी बिंदु पर मेरे पास "यूनिट टेस्ट" होता है जो इतना कवर करता है कि मैं इसे अक्सर "..IntegrationTest" का नाम देता हूं - केवल एक नाम बदलता है, और कुछ भी नहीं बदलता है।

मुझे लगता है कि इकाई परीक्षण (कक्षा स्तर) और एकीकरण परीक्षणों के लिए "परमाणु परीक्षण" (एक छोटी कक्षा, या एक विधि का परीक्षण) से एक निरंतरता है - और फिर कार्यात्मक परीक्षण (जो आमतौर पर ऊपर से बहुत अधिक सामान को कवर कर रहे हैं) - एक साफ कट ऑफ प्रतीत नहीं होता है।

यदि आपका परीक्षण डेटा सेट करता है, और शायद डेटाबेस / फ़ाइल इत्यादि लोड करता है, तो शायद यह एकीकरण परीक्षण का अधिक है (एकीकरण परीक्षण जो मुझे कम मोजे और अधिक वास्तविक कक्षाओं का उपयोग करता है, लेकिन इसका मतलब यह नहीं है कि आप कुछ को मजाक नहीं कर सकते प्रणाली में)।


यूनिट परीक्षण परीक्षण का एक तरीका है जो सत्यापित करता है कि स्रोत कोड की अलग-अलग इकाइयां ठीक से काम कर रही हैं।

एकीकरण परीक्षण सॉफ्टवेयर परीक्षण का चरण है जिसमें व्यक्तिगत सॉफ़्टवेयर मॉड्यूल को समूह के रूप में संयुक्त और परीक्षण किया जाता है।

विकिपीडिया एक इकाई को एक अनुप्रयोग के सबसे छोटे टेस्टेबल भाग के रूप में परिभाषित करता है, जो जावा / सी # में एक विधि है। लेकिन शब्द और वाक्य वर्ग के आपके उदाहरण में मैं शायद वाक्य के लिए परीक्षण लिखूंगा क्योंकि मुझे वाक्य वर्ग का परीक्षण करने के लिए एक mock शब्द वर्ग का उपयोग करने की संभावना अधिक होगी। तो वाक्य मेरी इकाई होगी और शब्द उस इकाई का एक कार्यान्वयन विवरण है।





integration-testing