Mockito.verify () का उपयोग कब करें?

Question

मैं 3 उद्देश्यों के लिए jUnit परीक्षण मामले लिखता हूं:

1. यह सुनिश्चित करने के लिए कि मेरा कोड इनपुट संयोजनों / मूल्यों के सभी (या अधिकांश) के तहत आवश्यक कार्यक्षमता के सभी को संतुष्ट करता है।
2. यह सुनिश्चित करने के लिए कि मैं कार्यान्वयन को बदल सकता हूं, और मुझे बताने के लिए JUnit परीक्षण मामलों पर भरोसा करें कि मेरी सारी कार्यक्षमता अभी भी संतुष्ट है।
3. सभी उपयोग के मामलों के दस्तावेज के रूप में मेरा कोड संभालता है, और रिफैक्टरिंग के लिए एक कल्पना के रूप में कार्य करता है - क्या कोड को कभी भी फिर से लिखना चाहिए। (कोड को रिफलेक्टर करें, और अगर मेरा जनीट परीक्षण विफल हो जाता है - आप शायद कुछ उपयोग के मामले में चूक गए हैं)।

मुझे समझ नहीं आ रहा है कि क्यों या कब Mockito.verify()इस्तेमाल किया जाना चाहिए। जब मैं देखता हूंverify() बुलाया जा रहा है, तो यह मुझे बता रहा है कि मेरे जेनेट कार्यान्वयन के बारे में जागरूक हो रहे हैं। (इस प्रकार मेरे कार्यान्वयन को बदलने से मेरे कार्य समाप्त हो जाएंगे, हालांकि मेरी कार्यक्षमता अप्रभावित थी)।

मैं देख रहा हूँ:

1. के उचित उपयोग के लिए दिशानिर्देश क्या होने चाहिए Mockito.verify()?

2. क्या यह बुनियादी तौर पर jUnits के बारे में जागरूक है, या कसकर युग्मित है, परीक्षण के तहत वर्ग के कार्यान्वयन के लिए सही है?

Comments

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

— हेगना

Answer 1

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

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

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

अपडेट करें:

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

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

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

Comments

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

— रसेल

@Russell भले ही "टाइप C" किसी लाइब्रेरी के आसपास या आपके एप्लिकेशन के कुछ अलग सबसिस्टम के आसपास रैपर के लिए एक इंटरफेस है?

— दाऊद इब्न करीम

मैं यह नहीं कहूंगा कि कुछ उप प्रणाली या सेवा को सुनिश्चित करने के लिए यह पूरी तरह से बेकार है - बस यह सुनिश्चित किया गया था कि इसके आस-पास कुछ दिशानिर्देश हों (उन्हें तैयार करना जो मैं करना चाहता था)। पूर्व के लिए: (मैं शायद इसे खत्म कर रहा हूँ) कहो, मैं अपने कोड में StrUtil.equals () का उपयोग कर रहा हूँ, और कार्यान्वयन में StrUtil.equalsIgnoreCase () पर स्विच करने का निर्णय लेता हूँ। JUnil ने सत्यापित (StrUtil.equals) किया था। ), मेरा परीक्षण विफल हो सकता है हालांकि कार्यान्वयन सटीक है। यह सत्यापित कॉल, IMO, बुरा अभ्यास है, हालांकि यह पुस्तकालयों / उप-प्रणालियों के लिए है। दूसरी ओर, क्लोजडबॉन्क को कॉल सुनिश्चित करने के लिए सत्यापन का उपयोग करना एक वैध उपयोग हो सकता है।

— रसेल

मैं आपको समझता हूं और आपके साथ पूरी तरह से सहमत हूं। लेकिन मुझे यह भी लगता है कि आपके द्वारा बताए गए दिशा-निर्देशों को पूरा करने के लिए संपूर्ण TDD या BDD पाठ्यपुस्तक लिखने में विस्तार हो सकता है। अपना उदाहरण लेने के लिए, कॉलिंग equals()या equalsIgnoreCase()कभी भी कुछ ऐसा नहीं होगा जो एक वर्ग की आवश्यकताओं में निर्दिष्ट था, इसलिए प्रति यूनिट कभी भी यूनिट टेस्ट नहीं होगा। हालांकि, "किए जाने पर DB कनेक्शन को बंद करना" (कार्यान्वयन के संदर्भ में जो भी इसका मतलब है) अच्छी तरह से एक वर्ग की आवश्यकता हो सकती है, भले ही यह "व्यावसायिक आवश्यकता" न हो। मेरे लिए, यह अनुबंध के बीच के रिश्ते के लिए नीचे आता है ...

— दाऊद इब्न करीम

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

— दाऊद इब्न करीम

Answer 2

डेविड का जवाब निश्चित रूप से सही है, लेकिन यह स्पष्ट नहीं करता है कि आप ऐसा क्यों चाहते हैं।

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

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

या, आप DAO का मज़ाक उड़ा सकते हैं और सत्यापित कर सकते हैं कि यह आपके द्वारा अपेक्षित तरीके से कॉल किया जाता है। मॉकिटो के साथ आप यह सत्यापित कर सकते हैं कि कुछ कहा जाता है, इसे कितनी बार कहा जाता है, और यहां तक ​​कि यह सुनिश्चित करने के लिए मापदंडों पर मिलान का उपयोग करता है कि यह किसी विशेष तरीके से कहा जाता है।

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

Answer 3

यह महान प्रश्न है! मुझे लगता है कि इसका मूल कारण निम्नलिखित है, हम JUnit का उपयोग केवल इकाई परीक्षण के लिए ही नहीं कर रहे हैं। इसलिए प्रश्न को विभाजित किया जाना चाहिए:

• क्या मुझे अपने एकीकरण में Mockito.verify () का उपयोग करना चाहिए (या किसी अन्य उच्चतर इकाई परीक्षण से) ?
• क्या मुझे अपने ब्लैक-बॉक्स में Mockito.verify () का उपयोग करना चाहिए यूनिट-परीक्षण ?
• क्या मुझे अपने व्हाइट-बॉक्स यूनिट-परीक्षण में Mockito.verify () का उपयोग करना चाहिए ?

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

अब, इस चरण-दर-चरण के बारे में जानें।

* - क्या मुझे अपने एकीकरण में Mockito.verify () का उपयोग करना चाहिए (या किसी अन्य उच्चतर इकाई परीक्षण ? * मुझे लगता है कि उत्तर स्पष्ट रूप से नहीं है, इसके अलावा आपको इसके लिए मॉक का उपयोग नहीं करना चाहिए। आपका परीक्षण यथासंभव वास्तविक आवेदन के करीब होना चाहिए। आप पूर्ण उपयोग के मामले का परीक्षण कर रहे हैं, आवेदन का अलग-थलग हिस्सा नहीं।

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

यदि आप व्हाइट-बॉक्स दृष्टिकोण का उपयोग कर रहे हैं तो आप वास्तव में क्या कर रहे हैं, आप अपनी इकाई के व्यवहार का परीक्षण कर रहे हैं । इस दृष्टिकोण में Mockito.verify () को कॉल करना आवश्यक है, आपको यह सत्यापित करना चाहिए कि आपकी इकाई जैसा आप उम्मीद कर रही है वैसा ही व्यवहार करती है।

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

यह वास्तव में कठिन है। मेरे पास एक अच्छा उदाहरण नहीं है, लेकिन मैं आपको उदाहरण दे सकता हूं। इस मामले में, जो कि बराबर () बनाम बराबर के साथ उल्लेख किया गया था (जैसे) आपको Mockito.verify () को कॉल नहीं करना चाहिए, बस आउटपुट का दावा करें। यदि आप ऐसा नहीं कर सकते, तो अपने कोड को छोटी इकाई तक तोड़ दें, जब तक आप ऐसा नहीं कर सकते। दूसरी ओर, मान लीजिए कि आपके पास कुछ @ सेवा है और आप @ वेब-सेवा लिख ​​रहे हैं जो आपके @ सेवा पर अनिवार्य रूप से आवरण है - यह सभी कॉल @ सेवा (और कुछ अतिरिक्त त्रुटि से निपटने) को दर्शाता है। इस मामले में Mockito.verify () के लिए कॉल करना आवश्यक है, आपको अपने सभी चेक डुप्लिकेट नहीं करने चाहिए, जो आपने @Serive के लिए किए थे, यह सत्यापित करते हुए कि आप @Service को सही पैरामीटर सूची के साथ बुला रहे हैं, पर्याप्त है।

Comments

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

— जिल्स वान गुरप

मेरे लिए यह सबसे अच्छा उपलब्ध उत्तर है क्योंकि यह जवाब देता है कि विभिन्न स्थितियों में मॉकिटो.वन () का उपयोग कब करना है। बहुत बढ़िया।

— मिकिएल लीगवाटर

Answer 4

मुझे कहना होगा, कि आप एक शास्त्रीय दृष्टिकोण से बिल्कुल सही हैं:

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

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

Answer 5

जैसा कि कुछ लोगों ने कहा

1. कभी-कभी आपके पास एक प्रत्यक्ष आउटपुट नहीं होता है, जिस पर आप दावा कर सकते हैं
2. कभी-कभी आपको केवल यह पुष्टि करने की आवश्यकता होती है कि आपका परीक्षण किया गया तरीका अपने सहयोगियों को सही अप्रत्यक्ष आउटपुट भेज रहा है (जो आप मजाक कर रहे हैं)।

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

Answer 6

ज्यादातर मामलों में जब लोग Mockito.verify का उपयोग करना पसंद नहीं करते हैं, तो इसका कारण यह है कि इसका उपयोग उन सभी चीज़ों को सत्यापित करने के लिए किया जाता है जो परीक्षण की गई इकाई कर रही है और इसका मतलब है कि आपको इसमें कुछ भी बदलाव होने पर अपने परीक्षण को अनुकूलित करने की आवश्यकता होगी। लेकिन, मुझे नहीं लगता कि यह कोई समस्या है। यदि आप यह बदलने में सक्षम होना चाहते हैं कि कोई विधि परीक्षण को बदलने की आवश्यकता के बिना क्या करती है, तो मूल रूप से इसका मतलब है कि आप ऐसे परीक्षण लिखना चाहते हैं जो आपके तरीके की हर चीज का परीक्षण नहीं करते हैं, क्योंकि आप नहीं चाहते कि यह आपके परिवर्तनों का परीक्षण करे। । और यह सोचने का गलत तरीका है।

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

उसकी वजह से, मैं जितना संभव हो उतना मज़ाक करना पसंद करता हूं: अपने डेटा ऑब्जेक्ट का भी मजाक उड़ाएं। ऐसा करते समय आप न केवल सत्यापित करने के लिए उपयोग कर सकते हैं कि अन्य वर्गों के सही तरीकों को कहा जाता है, बल्कि यह भी कि पारित किए जा रहे डेटा को उन डेटा ऑब्जेक्ट्स के सही तरीकों के माध्यम से एकत्र किया जाता है। और इसे पूरा करने के लिए, आपको उस आदेश का परीक्षण करना चाहिए जिसमें कॉल होते हैं। उदाहरण: यदि आप एक db निकाय ऑब्जेक्ट को संशोधित करते हैं और फिर एक रिपॉजिटरी का उपयोग करके इसे सहेजते हैं, तो यह सत्यापित करने के लिए पर्याप्त नहीं है कि ऑब्जेक्ट के सेटर को सही डेटा के साथ कहा जाता है और रिपॉजिटरी की सेव विधि को कहा जाता है। यदि उन्हें गलत क्रम में बुलाया जाता है, तो आपकी विधि अभी भी वह नहीं करती है जो उसे करना चाहिए। इसलिए, मैं Mockito.verify का उपयोग नहीं करता हूं, लेकिन मैं सभी मौकों के साथ inOrder ऑब्जेक्ट बनाता हूं और इसके बजाय inOrder.verify का उपयोग करता हूं। और अगर आप इसे पूरा करना चाहते हैं, तो आपको मॉकिटो को भी कॉल करना चाहिए। अंत में VerNoMoreInteractions सत्यापित करें और इसे सभी मोक्स पास करें। अन्यथा कोई व्यक्ति बिना परीक्षण के नई कार्यक्षमता / व्यवहार जोड़ सकता है, जिसका अर्थ होगा कि आपके कवरेज के आंकड़े 100% हो सकते हैं और फिर भी आप कोड को जमा कर रहे हैं जो कि सत्यापित या सत्यापित नहीं है।