🌸 🌇 ⛹🏿 मॉकिटो और इसे कैसे पकाने के लिए ☃️ 💇 🗿

लेख के बारे में

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

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

सामग्री:

मॉकिटो: यह क्या है और क्यों आवश्यक है

संक्षेप में, मॉकिटो एक स्टब फ्रेमवर्क है।

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

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

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

पर्यावरण, संस्करण और प्रयोगात्मक जानवर

इस लेख को लिखते समय, मैंने उपयोग किया:

मॉकिटो: 'org.mockito: मॉकिटो-कोर: 2.24.0' (लेखन के समय नवीनतम स्थिर संस्करण)
TestNG: 'org.testng: testng: 6.14.3' एक परीक्षण ढांचे के रूप में
AssertJ: 'org.assertj: assertj-core: 3.11.1' एक सत्यापन उपकरण के रूप में
लोम्बोक: 'org.projectlombok: lombok: 1.18.6' (सिर्फ सुविधा के लिए)
जावा 8

मेरे अमानवीय प्रयोगों के लिए, मैंने एक सेवा का यह इंटरफ़ेस लिखा है जो कुछ डेटा तक पहुंच प्रदान करता है।

 public interface DataService { void saveData(List<String> dataToSave); String getDataById(String id); String getDataById(String id, Supplier<String> calculateIfAbsent); List<String> getData(); List<String> getDataListByIds(List<String> idList); List<String> getDataByRequest(DataSearchRequest request); }

और यह (यह आदेश के लिए होने दें) इंटरफ़ेस विधियों के अंतिम में दिए गए अनुरोध वर्ग का कोड।

 @AllArgsConstructor @Getter class DataSearchRequest { String id; Date updatedBefore; int length; }

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

मैं तुरंत ध्यान दूंगा: नीचे दिए गए उदाहरणों में, मैं सीधे तौर पर स्पष्टता के लिए अपनी नकली वस्तुओं की ओवरराइड विधियों को कहता हूं, लेकिन वास्तविक परीक्षण के साथ विचार बिल्कुल नहीं है! इस परीक्षण में, मैं निम्नलिखित कार्य लगातार करूंगा:

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

मजाक और जासूसी

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

DataService वर्ग का मज़ाक बनाने के लिए, मुझे बस निम्नलिखित कार्य करने होंगे:

 DataService dataServiceMock = Mockito.mock(DataService.class);

हो गया - मुझे उस वर्ग का उदाहरण मिला जिसकी मुझे आवश्यकता है। यह किसी भी विधि या निर्माणकर्ता द्वारा स्वीकार किया जाएगा जिसे इस प्रकार के पैरामीटर की आवश्यकता होती है (उदाहरण के लिए, उस वर्ग का निर्माणकर्ता जिसे मैं परीक्षण करना चाहता हूं)। यहां तक कि अगर एक व्यसनी जांच बाद में इंतजार करता है, तो वह इसे पास करेगा: न केवल dataServiceMock.getClass() true लौटेगी, बल्कि dataServiceMock.getClass() भी dataServiceMock.getClass() - अर्थात् dataServiceMock.getClass() । कुछ औपचारिक तरीके से, एक साधारण से एक मॉक ऑब्जेक्ट को प्रोग्रामेटिक रूप से अलग करने के लिए एक मुश्किल काम है, जो कि तार्किक है: आखिरकार, पहले का उद्देश्य सिर्फ दूसरे से अप्रभेद्य होना है। हालांकि, मॉकिटो के पास इसके लिए एक उपकरण है - Mockito.mockingDetails विधि। इसे एक मनमाना ऑब्जेक्ट पास करके, मुझे MockingDetails क्लास का ऑब्जेक्ट मिलता है। इसमें इस बात की जानकारी है कि यह वस्तु मॉकिटो के दृष्टिकोण से क्या दर्शाती है: चाहे वह नकली हो, जासूसी हो (नीचे देखें), इसका उपयोग कैसे किया गया, यह कैसे बनाया गया और इसी तरह।

विशेष ध्यान देने की स्थिति वह स्थिति है जब मैं अंतिम वर्ग के लिए एक नकली बनाने या एनम के एक नकली उदाहरण बनाने या अंतिम विधि के व्यवहार को ओवरराइड करने का प्रयास करता हूं। इस मामले में, मॉकिटो के डिफ़ॉल्ट व्यवहार के साथ, कोड ऊपर काम करने से इनकार करता है, ठीक इसी परिस्थिति का हवाला देते हुए। हालाँकि, इसे बदला जा सकता है - प्रोजेक्ट में बनाएँ (प्रोजेक्ट डायरेक्टरी ट्री के मानक उपकरण के साथ) फ़ाइल test/resources/mockito-extensions/org.mockito.plugins.MockMaker और इसमें लाइन डालें:

 mock-maker-inline

उसके बाद, आप सामान्य तरीके से अंतिम कक्षाओं और एनम की नकल कर सकते हैं, साथ ही साथ अंतिम तरीकों को ओवरराइड भी कर सकते हैं।

मुझे जो एक्शन मिला वह जितना संभव हो उतना निराधार है: किसी भी तरीके का किसी भी चीज पर कोई प्रभाव नहीं पड़ेगा, और लौटाया गया मूल्य ऑब्जेक्ट प्रकारों के लिए null होगा और आदिम लोगों के लिए 0 । कृपया ध्यान दें: यदि विधि एक संग्रह लौटाती है, तो डिफ़ॉल्ट मॉक null नहीं लौटेगा, लेकिन संग्रह खाली है। उदाहरण के लिए, List यह एक खाली LinkedList भले ही वास्तविक विधि वापस आ गई हो। लेकिन सरणियों, आदिम या वस्तु के मूल्यों के रूप में, मैं null हो जाता हूं। डिफ़ॉल्ट व्यवहार (और न केवल यह) MockSettings वर्ग की कार्यक्षमता का उपयोग करके बदला जा सकता है, लेकिन यह शायद ही कभी आवश्यक है।

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

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

 DataService dataServiceSpy = Mockito.spy(DataService.class); // or DataService dataService = new DataService(); dataServiceSpy = Mockito.spy(dataService);

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

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

व्यवहार प्रबंधन

तो, कैसे मैं क्या जरूरत है करने के लिए नकली या जासूसी पाने के लिए। इसके अलावा, मैं हमेशा हर जगह बस "नकली" लिखूंगा - इसका मतलब "नकली या जासूस" होगा, जब तक कि अन्यथा स्पष्ट रूप से न कहा जाए।

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

मुख्य कार्यान्वयन Mockito.when पद्धति पर आधारित है। यह विधि "पैरामीटर" के रूप में मॉक-ऑब्जेक्ट के पुनर्निर्धारित विधि के लिए कॉल करती है (इस तरह से पता चला क्रिया निश्चित है) और प्रकार की एक वस्तु को OngoingStubbing , जो OngoingStubbing के तरीकों में से एक को कॉल करने की अनुमति देती है Mockito.then... परिवार (यह इस प्रभाव पर प्रतिक्रिया कैसे सेट होती है)। सभी एक साथ, सबसे सरल मामले में, यह कुछ इस तरह दिखता है:

 List<String> data = new ArrayList<>(); data.add("dataItem"); Mockito.when(dataService.getAllData()).thenReturn(data);

इस ऑपरेशन के बाद, getAllData() ऑब्जेक्ट पर getAllData() विधि को कॉल करके, मुझे सूची की पहली पंक्ति में निर्दिष्ट ऑब्जेक्ट मिलता है।

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

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

हालत और कॉल के परिणाम को जोड़ने का एक वैकल्पिक कार्यान्वयन Mockito.do... परिवार के तरीके हैं। ये विधियां आपको कॉल के परिणाम से शुरू होने वाले व्यवहार को सेट करने और Stubber क्लास की एक वस्तु वापस करने की अनुमति देती हैं, जिसके साथ आप पहले से ही शर्त सेट कर सकते हैं। इस तरह से ऊपर किया गया बंधन इस तरह दिखता है:

 List<String> data = new ArrayList<>(); data.add("dataItem"); Mockito.doReturn(data).when(dataService).getData()

क्या अंतर है, क्यों Mockito.when माध्यम से बाध्यकारी बेहतर माना जाता है और जब आपको अभी भी Mockito.do... के तरीकों का उपयोग करना है Mockito.do... ? कृपया ध्यान दें: पहले कार्यान्वयन में, विधि के व्यवहार को सेट करते समय (इस मामले में, getAllData() ), उस संस्करण के लिए कॉल जिसे अभी तक फिर से परिभाषित नहीं किया गया है, और केवल तभी, getAllData() में, एक ओवरराइड होता है। दूसरे में, इस तरह की कॉल नहीं होती है - Stubber.when विधि सीधे Stubber.when पास जाती है। Stubber.when विधि की जाती है, और इस विधि द्वारा लौटाए गए एक ही प्रकार का एक ऑब्जेक्ट होता है, लेकिन एक अलग प्रकृति को एक अतिव्याप्त विधि के साथ कहा जाता है। यह अंतर सब कुछ निर्धारित करता है। Mockito.do... माध्यम से बाइंडिंग Mockito.do... संकलन चरण पर बिल्कुल भी नियंत्रण नहीं करता है कि मैं किस पुनर्निर्देशन विधि को कॉल करूंगा और क्या यह दिए गए रिटर्न मान के साथ प्रकार में संगत है। इसलिए, आमतौर पर Mockito.when बेहतर है - इसमें कोई गलती नहीं हो सकती है। लेकिन ऐसे मामले हो सकते हैं जब मैं एक ओवरराइड विधि को कॉल करने से बचना चाहता हूं - हौसले से बनाए गए मॉक के लिए, इस तरह की कॉल काफी स्वीकार्य है, लेकिन अगर मैंने पहले से ही इस पद्धति को फिर से परिभाषित किया है या जासूसी से निपटना है, तो यह अवांछनीय हो सकता है, और एक अपवाद को फेंकने से आवश्यक पुनर्वित्त की अनुमति नहीं होगी। । और यहाँ Mockito.do... माध्यम से बाध्यकारी Mockito.do... लिए आता है Mockito.do...

एक और स्थिति जहां आप Mockito.do... बिना नहीं कर सकते हैं Mockito.do... विधियाँ void लौटाने वाली विधि को ओवरराइड कर रही हैं: लंबित Mockito.when पैरामीटर ऐसी विधि के साथ काम नहीं कर सकता है। Mockito.doReturn यहाँ Mockito.doReturn है, लेकिन Mockito.doThrow , Mockito.doAnswer और शायद ही कभी पर्याप्त Mockito.doNothing ।

अगला, मैं थोड़ा और विस्तार से विचार करूंगा कि कॉल की स्थिति और परिणाम कैसे सेट करें। मैं केवल Mockito.when माध्यम से बाध्यकारी पर विचार Mockito.when - एक वैकल्पिक तरीका हैंडलिंग में लगभग पूरी तरह से समान है।

कॉल की स्थिति सेट करना

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

 String getDataItemById(String id) { // some code... }

अगर मुझे तर्कों की परवाह किए बिना इस तरीके से किसी भी कॉल का जवाब देने की आवश्यकता है, तो मुझे Mockito.any विधि का उपयोग करना होगा:

 Mockito.when(dataService.getDataItemById(any())) .thenReturn("dataItem");

यदि मुझे तर्क के केवल एक निश्चित मूल्य पर प्रतिक्रिया करने के लिए नकली की आवश्यकता है, तो आप इस मूल्य का उपयोग सीधे या Mockito.eq के तरीकों (यदि यह एक समतुल्यता है) या Mockito.same (यदि लिंक तुलना की आवश्यकता है) कर सकते हैं:

 Mockito.when(dataService.getDataItemById("idValue")) .thenReturn("dataItem"); // or Mockito.when(dataService.getDataItemById(Mockito.eq("idValue"))) .thenReturn("dataItem");

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

 Mockito.when(dataService.getDataById( Mockito.argThat(arg -> arg == null || arg.length() > 5))) .thenReturn("dataItem");

ArgumentMatchers और AdditionalMatchers क्लासेस आपको इस इंटरफ़ेस के कुछ उपयोगी ऑफ-द-शेल्फ कार्यान्वयन के साथ काम करने की अनुमति देते हैं। उदाहरण के लिए, extraMatchers.or और extraMatchers.and आपको अन्य मिलानकर्ताओं को संयोजित करने की अनुमति देते हैं (ध्यान दें: इन वर्गों के स्थिर तरीके मैचर्स के उदाहरणों को वापस नहीं करते हैं, लेकिन केवल उन्हें एक्सेस करते हैं!)

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

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

इसके अलावा, जब ऐसी विधि के व्यवहार को निर्दिष्ट किया जाता है, तो कोई Mockito और मूल्यों के प्रत्यक्ष हस्तांतरण का Mockito स्थैतिक Mockito विधियों को जोड़ नहीं सकता है। Mockito.eq या Mockito.same उपयोग करें।

कॉल रिजल्ट सेट करना

मॉक ऑब्जेक्ट विधि को कॉल करने के बाद, ऑब्जेक्ट को कॉल का जवाब देना चाहिए। मुख्य संभावित परिणाम परिणाम लौटा रहे हैं और एक अपवाद फेंक रहे हैं, और यह इन विकल्पों पर ठीक है कि मॉकिटो टूलकिट मुख्य रूप से डिज़ाइन किया गया है।

पहले से ही दिखाए गए सरलतम मामले में, कॉल का जवाब एक मूल्य वापस करना है। मैं फिर से उसका कोड दूंगा:

 List<String> data = new ArrayList<>(); data.add("dataItem"); Mockito.when(dataService.getAllData()).thenReturn(data);

कृपया ध्यान दें: आप केवल एक वस्तु वापस कर सकते हैं, आदिम के लिए कोई अलग तरीके नहीं हैं। इसलिए, यदि विधि एक आदिम मान लौटाती है, तो ऐसी स्थिति में संयुक्त राष्ट्र / मुक्केबाजी होगी। ज्यादातर मामलों में, यह हस्तक्षेप नहीं करता है, लेकिन यदि कंपाइलर अन्यथा सोचता है, तो आपको किसी तरह उसके साथ सहमत होना होगा ... या उसकी चेतावनियों के साथ रखा जाएगा।

अपवाद फेंकना कठिन नहीं है:

 Mockito.when(dataService.getDataById("invalidId")) .thenThrow(new IllegalArgumentException());

एक और तरीका है: आप एक अपवाद ऑब्जेक्ट बना सकते हैं और इसे सीधे फेंक सकते हैं, या आप केवल एक अपवाद वर्ग के साथ मॉकिटो प्रदान कर सकते हैं ताकि यह स्वचालित रूप से बनाया जाए:

 Mockito.when(dataService.getDataById("invalidId")) .thenThrow(IllegalArgumentException.class);

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

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

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

 Mockito.when(dataService.getDataByIds(Mockito.any())) .thenAnswer(invocation -> invocation .<List<String>>getArgument(0).stream() .map(id -> { switch (id) { case "a": return "dataItemA"; case "b": return "dataItemB"; default: return null; } }) .collect(Collectors.toList()));

वैचारिक रूप से, यह एक वास्तविक विधि का एक मॉडल लिखने की तरह कुछ है: मापदंडों को प्राप्त करना, प्रसंस्करण करना, परिणाम वापस करना। - , - , , , mock- .

Answer , , — , AnswersWithDelay , ReturnsElementsOf . .

: InvocationOnMock — Object[] , generic-.

— thenCallRealMethod . . mock-, spy-. mock , , - null . spy thenCallRealMethod spy ; , - .

thenAnswer : InvocationOnMock callRealMethod() — , "" - .

OngoingStubbing OngoingStubbing , , , . , . thenReturn thenThrow , varargs. .

 Mockito.when(dataService.getDataById("a")) .thenReturn("valueA1", "valueA2") .thenThrow(IllegalArgumentException.class);

"valueA1 , — "valueA2 ( ), ( ) IllegalArgumentException .

: (mock' ), . , : , , . verify .

, , :

 Mockito.verify(dataService).getDataById(Mockito.any());

, getDataById , , . , Mockito, when , , , mock-. , , , when , — mock', (. ).

 Mockito.verify(dataService, Mockito.times(1)) .getDataById(Mockito.any());

Mockito.times ; Mockito.never . Mockito.atLeast ( Mockito.atLeastOnce 1) Mockito.atMost , , Mockito.only , , mock- (. . ).

, Mockito , VerificationAfterDelay VerificationWithTimeout , Mockito.after Mockito.timeout . उदाहरण के लिए:

 Mockito.verify(dataService, Mockito.after(1000).times(1)) .getDataById(Mockito.any());

, mock , , , . . after timeout , , , — , . , timeout — . VerificationWithTimeout never atMost : .

, Mockito.any() . , , — Mockito , , . Mock- , , , , :

 dataService.getDataById("a"); dataService.getDataById("b"); Mockito.verify(dataService, Mockito.times(2)).getDataById(Mockito.any()); Mockito.verify(dataService, Mockito.times(1)).getDataById("a"); Mockito.verify(dataService, Mockito.never()).getDataById("c"); dataService.getDataById("c"); Mockito.verify(dataService, Mockito.times(1)).getDataById("c"); Mockito.verifyNoMoreInteractions(dataService);

verifyNoMoreInteractions ( verifyZeroInteractions ) — - ( verify ) mock- — . : varargs, , , !

, , , . , InOrder :

 InOrder inOrder = Mockito.inOrder(dataService);

varargs; — mock- , InOrder . verify , Mockito.verify :

 inOrder.verify(dataService, times(2)).saveData(any()); inOrder.verify(dataService).getData();

, saveData , — getData . , InOrder , — .

, , — , . - , , — , , . ArgumentCaptor capture() . उदाहरण के लिए:

 DataSearchRequest request = new DataSearchRequest("idValue", new Date(System.currentTimeMillis()), 50); dataService.getDataByRequest(request); ArgumentCaptor<DataSearchRequest> requestCaptor = ArgumentCaptor.forClass(DataSearchRequest.class); Mockito.verify(dataService, times(1)).getDataByRequest(requestCaptor.capture()); assertThat(requestCaptor.getAllValues()).hasSize(1); DataSearchRequest capturedArgument = requestCaptor.getValue(); assertThat(capturedArgument.getId()).isNotNull(); assertThat(capturedArgument.getId()).isEqualTo("idValue"); assertThat(capturedArgument.getUpdatedBefore()).isAfterYear(1970); assertThat(capturedArgument.getLength()).isBetween(0, 100);

ArgumentCaptor , , ArgumentCaptor . getValue() , getAllValues() — . , , .

Mock- Mockito

, mock- , — @Mock - :

 MockitoAnnotations.initMocks(this);

( , mock', )

spy @Spy — @Mock … spy , , ? , — spy .

@Captor ArgumentCaptor — , , .

@InjectMocks . - Mockito, . mock- , . , . - , null , - . ( ) dependency injection.

Mockito

, : mock (spy, argument captor...), , , . , mock' — , . JUnit , , TestNG — . , , mock' , , , . . , , — , .

, mock- . TestNG @BeforeMethod ( @AfterMethod ). mock' , , ( JUnit — @Before ).

, , — Mockito.reset Mockito.clearInvocations . varargs, mock'. , . : (, ) , / mock' , — . , mock' . . , , .

(, ) — MockitoAnnotations.initMocks(this); । "" , Mockito.

— Mockito. . mock- , ( mock' ). , MockitoSession , . TestNG:

 @Mock DataService dataService; MockitoSession session; @BeforeMethod public void beforeMethod() { session = Mockito.mockitoSession() .initMocks(this) .startMocking(); } @Test public void testMethod() { // some code using the dataService field } @AfterMethod public void afterMethod() { session.finishMocking(); }

, — , "" (, ) , .

?

Mockito: mock spy-, . , . , , :

Mockito mock- MockSettings ( — , mock' - );
mock-, MockingDetails ;
BDDMockito Mockito ;
( JUnit Mockito, ).

Mockito . javadoc' Mockito .

, , .

मॉकिटो और इसे कैसे पकाने के लिए