मेरे लिए महत्वपूर्ण अंतर यह है कि एकीकरण परीक्षण से पता चलता है कि कोई विशेषता काम कर रही है या टूट गई है, क्योंकि वे वास्तविकता के करीब एक परिदृश्य में कोड को तनाव देते हैं। वे एक या एक से अधिक सॉफ्टवेयर विधियों या विशेषताओं को लागू करते हैं और यदि वे अपेक्षित रूप से कार्य करते हैं तो परीक्षण करते हैं।
इसके विपरीत, एक इकाई परीक्षण एक एकल विधि परीक्षण (अक्सर गलत) पर निर्भर करता है कि बाकी सॉफ्टवेयर सही तरीके से काम कर रहा है, क्योंकि यह स्पष्ट रूप से प्रत्येक निर्भरता का मजाक उड़ाता है।
इसलिए, जब किसी सुविधा को लागू करने वाली विधि के लिए एक इकाई परीक्षण हरा होता है, तो इसका मतलब यह नहीं है कि यह सुविधा काम कर रही है।
आप इस तरह से कहीं एक विधि है कहते हैं:
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
Log.TrackTheFactYouDidYourJob();
return someResults;
}
DoSomethingआपके ग्राहक के लिए बहुत महत्वपूर्ण है: यह एक विशेषता है, केवल एक चीज जो मायने रखती है। आप करना चाहते हैं: यही कारण है कि आप आमतौर पर एक ककड़ी विनिर्देश यह जोर देते हुए लिखना है सत्यापित करने और संवाद सुविधा या काम नहीं कर रहा।
Feature: To be able to do something
In order to do something
As someone
I want the system to do this thing
Scenario: A sample one
Given this situation
When I do something
Then what I get is what I was expecting for
इसमें कोई संदेह नहीं है: यदि परीक्षा पास हो जाती है, तो आप दावा कर सकते हैं कि आप एक काम कर रहे हैं। इसे आप बिजनेस वैल्यू कह सकते हैं ।
यदि आप एक इकाई परीक्षण लिखना चाहते हैं, तो आपको DoSomething(कुछ मोक्स का उपयोग करके) दिखावा करना चाहिए कि बाकी कक्षाएं और विधियां काम कर रही हैं (अर्थात: वह, जो सभी निर्भरताएं विधि का सही तरीके से उपयोग कर रही हैं) और आपकी विधि काम कर रही है।
व्यवहार में, आप कुछ ऐसा करते हैं:
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
return someResults;
}
आप इसे डिपेंडेंसी इंजेक्शन, या कुछ फैक्ट्री मेथड या किसी मॉक फ्रेमवर्क के साथ कर सकते हैं या सिर्फ टेस्ट के तहत क्लास को बढ़ा सकते हैं।
मान लीजिए कि एक बग है Log.DoSomething()। सौभाग्य से, गेरकिन कल्पना इसे ढूंढ लेगी और आपके एंड-टू-एंड परीक्षण विफल हो जाएंगे।
सुविधा काम नहीं करेगी, क्योंकि Logटूटी हुई है, इसलिए नहीं कि [Do your job with someInput]अपना काम नहीं कर रही है। और, वैसे, [Do your job with someInput]उस पद्धति के लिए एकमात्र जिम्मेदारी है।
इसके अलावा, मान लिया Logजाता है कि 100 अन्य सुविधाओं में, 100 अन्य वर्गों के 100 अन्य तरीकों में।
हां, 100 फीचर्स फेल हो जाएंगे। लेकिन, सौभाग्य से, 100 अंत-टू-एंड परीक्षण असफल हो रहे हैं और समस्या का खुलासा कर रहे हैं। और, हाँ: वे सच कह रहे हैं ।
यह बहुत उपयोगी जानकारी है: मुझे पता है कि मेरे पास एक टूटा हुआ उत्पाद है। यह बहुत भ्रमित करने वाली जानकारी है: यह मुझे बताता है कि समस्या कहां है। यह मुझे लक्षण बताता है, मूल कारण नहीं।
फिर भी, DoSomethingइकाई परीक्षण हरा है, क्योंकि यह एक नकली का उपयोग कर रहा है Log, कभी नहीं तोड़ने के लिए बनाया गया है। और, हाँ: यह स्पष्ट रूप से झूठ है । यह एक टूटी हुई सुविधा का संचार कर रहा है। यह कैसे उपयोगी हो सकता है?
(यदि मैं DoSomething()इकाई परीक्षण विफल रहता है, तो सुनिश्चित करें: [Do your job with someInput]कुछ कीड़े हैं।)
मान लीजिए कि यह एक टूटे हुए वर्ग के साथ एक प्रणाली है:
एक एकल बग कई सुविधाओं को तोड़ देगा, और कई एकीकरण परीक्षण विफल हो जाएंगे।
दूसरी ओर, एक ही बग केवल एक इकाई परीक्षण को तोड़ देगा।
अब, दो परिदृश्यों की तुलना करें।
एक ही बग केवल एक इकाई परीक्षण को तोड़ देगा।
- टूटी हुई का उपयोग कर आपकी सभी विशेषताएं
Logलाल हैं
- आपके सभी यूनिट परीक्षण हरे हैं, केवल इकाई परीक्षण
Logलाल है
दरअसल, एक टूटी हुई सुविधा का उपयोग करते हुए सभी मॉड्यूल के लिए यूनिट परीक्षण हरे होते हैं क्योंकि, मोज़ेक का उपयोग करके, उन्होंने निर्भरता को हटा दिया। दूसरे शब्दों में, वे एक आदर्श, पूरी तरह से काल्पनिक दुनिया में चलते हैं। और यह बग को अलग करने और उन्हें तलाशने का एकमात्र तरीका है। यूनिट टेस्टिंग का मतलब है मॉकिंग। यदि आप मजाक नहीं कर रहे हैं, तो आप इकाई परीक्षण नहीं कर रहे हैं।
अंतर
एकीकरण परीक्षण बताते हैं कि क्या काम नहीं कर रहा है। लेकिन वे अनुमान लगाने में किसी काम के नहीं हैं कि समस्या कहाँ हो सकती है।
यूनिट परीक्षण एकमात्र परीक्षण हैं जो आपको बताते हैं कि वास्तव में बग कहां है। इस जानकारी को आकर्षित करने के लिए, उन्हें एक नकली वातावरण में विधि को चलाना चाहिए, जहाँ अन्य सभी निर्भरताएँ सही ढंग से काम करने वाली हों।
इसलिए मुझे लगता है कि आपका वाक्य "या यह सिर्फ एक इकाई परीक्षण है जो 2 वर्गों तक फैला है" किसी तरह विस्थापित हो गया है। एक यूनिट टेस्ट में कभी भी 2 कक्षाएं नहीं होनी चाहिए।
यह उत्तर मूल रूप से मेरे द्वारा यहां लिखे गए का एक सारांश है: यूनिट परीक्षण झूठ बोलते हैं, इसलिए मैं उनसे प्यार करता हूं ।
