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

इस लेख में, मैं जावा: ईज़ीमॉक और जेमॉक में मोक्स के साथ काम करने के लिए दो सामान्य पुस्तकालयों का तुलनात्मक विश्लेषण करूंगा । JUnit का बुनियादी ज्ञान समझने के लिए पर्याप्त है, और इस लेख को पढ़ने के बाद आपको इन दोनों पुस्तकालयों का उपयोग करने का एक बहुत अच्छा विचार होगा।

प्रश्न में कार्य

परीक्षण किए जाने की आवश्यकता के एक उदाहरण के रूप में, हम कुछ एप्लिकेशन पर विचार करेंगे जिनमें लगभग निम्नलिखित संरचना है:

1 2 3 4 5 6 7 8 9

public class WayTooComplexClass { public WayTooComplexClass(String serverAddress) {/*...*/} public boolean save(long id, String data) {/*...*/} public String get(long id) {/*...*/} }

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

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

इस बिंदु पर कुछ लोग कहते हैं कि उनका "कोड यूनिट परीक्षणों के लिए बहुत जटिल है" ™ , और वे लेखन के साथ भरा हुआ है। सौभाग्य से, हम उनमें से एक नहीं हैं, और इसलिए हम सीधे परीक्षण से एक छोटा HTTP सर्वर बढ़ाएंगे, जो सही तरीके से आवश्यक अनुरोधों का जवाब देगा। इस उदाहरण में, मैंने ऐसे उद्देश्यों के लिए जेटी का उपयोग किया। मॉक लाइब्रेरी का उपयोग करते समय ऐसा कोड सामान्य होगा:

परीक्षण के लिए मॉक सर्वर ^{(आप इसे नहीं पढ़ सकते हैं)}

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

public class WayTooComplexClassTest { static interface RequestHandler { String handle(String target, String data); } private static class MockHttpServerHandler extends AbstractHandler { private RequestHandler handler; public void setRequestHandler(RequestHandler handler) { this.handler = handler; } @Override public void handle(String target, HttpServletRequest request, HttpServletResponse response, int dispatch ) throws IOException, ServletException { String req = IOUtils.toString(request.getInputStream(), "UTF-8"); String result = handler.handle(target, req); response.setStatus(HttpStatus.ORDINAL_200_OK); response.setContentType("text/plain"); final ServletOutputStream outputStream = response.getOutputStream(); try { outputStream.print(result); } finally { outputStream.close(); } } } private static final MockHttpServerHandler SERVER_HANDLER = new MockHttpServerHandler(); @BeforeClass public static void startServer() throws Exception { org.mortbay.jetty.Server server = new org.mortbay.jetty.Server(); server.setHandler(SERVER_HANDLER); server.start(); } private final WayTooComplexClass wayTooComplex = new WayTooComplexClass("http://localhost/9001"); //Tests go here }

यहां हमारे पास तीन दिलचस्प बिंदु हैं। पहली पंक्ति 3-5 है, जिसमें RequestHandler इंटरफ़ेस का वर्णन किया गया है, जो अनुरोध लक्ष्य प्राप्त करता है ( उदाहरण के लिए, पता http: // habrahabr। W / ब्लॉग / जावा / 136466 / पर लक्ष्य बोल्ड / ब्लॉग / जावा / 136466 / ) होगा। अनुरोध निकाय में उपयोगकर्ता द्वारा भेजा गया डेटा। दूसरा 32 के माध्यम से 7 पंक्तियाँ है - MockHttpServerHandler वर्ग। RequestHandler स्थापित किया गया RequestHandler , जिसमें पूरे "व्यावसायिक तर्क" को प्रत्यायोजित किया गया है, और इसके कार्य का परिणाम HTTP प्रतिक्रिया में दर्ज किया गया है। और तीसरी - लाइनें 36-41 - startServer विधि है, जो, जैसा कि आप एनोटेशन और नाम से अनुमान लगा सकते हैं, इस वर्ग में सूचीबद्ध किसी भी परीक्षण को शुरू करने और HTTP सर्वर को शुरू करने से पहले कहा जाता है।

पहला और सबसे आसान परीक्षण

मान लीजिए कि, सिद्धांत रूप में, सेव विधि में छिपा कोड url {serverAddress}/upload/{id} माध्यम से जाना चाहिए और वहां data पास data चाहिए। जांचें कि क्या यह वास्तव में हो रहा है।

JMock

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Mockery context = new JUnit4Mockery(); @Test public void testSaveWithJMock() { final long id = 13; final String data = "nanofilters"; final RequestHandler requestHandler = context.mock(RequestHandler.class); context.checking(new Expectations() {{ one(requestHandler).handle("/upload/" + id, data); will(returnValue("Saved " + id)); }}); SERVER_HANDLER.setRequestHandler(requestHandler); wayTooComplex.save(id, data); context.assertIsSatisfied(); }

पहली पंक्ति में, हमें एक JMock संदर्भ बनाने की आवश्यकता है जिसमें परीक्षण चलाया जाएगा। यह संदर्भ पूरे परीक्षण के लिए पर्याप्त है, लेकिन आप इसके बिना नहीं कर सकते । उसी के कई मोकों के साथ समस्याओं से बचने के लिए, आपको प्रत्येक परीक्षण से पहले संदर्भ को बनाना चाहिए (अर्थात, @Before एनोटेशन के साथ चिह्नित विधि के अंदर) आठवीं पंक्ति में, हम आसानी से और स्वाभाविक रूप से हमारे इंटरफ़ेस के लिए नकली बनाते हैं। अगला, १०-१३ की पंक्तियों में, हम बताते हैं कि कॉल क्या होनी चाहिए पहली नज़र में वाक्य रचना बहुत सहज नहीं है , लेकिन आपको समय के साथ इसकी आदत हो जाती है। पंक्ति 11 में हमने संकेत दिया कि हम तर्कों ("/upload/" + id) और (data) साथ handle विधि के लिए एक कॉल की अपेक्षा करते हैं। पंक्ति 12 में हम कहते हैं कि अंतिम कॉल एक मान लौटाएगा ("Saved " + id) । यहां, जैसा कि आप अनुमान लगा सकते हैं, कोई विशिष्ट सुरक्षा नहीं है । हम गलती से वहां गलत प्रकार का मान पारित कर सकते हैं और इसके बारे में केवल रनटाइम में सीख सकते हैं, जिसमें श्लोपोट अपवाद है। लेकिन अगर रिटर्न वैल्यू महत्वपूर्ण नहीं है, तो आप यह बिल्कुल नहीं लिख सकते हैं: जेमॉक स्वचालित रूप से डिफ़ॉल्ट मान ( 0 , false , null या खाली स्ट्रिंग) लौटाएगा। इसके बाद, हम अपने मॉक सर्वर को बताते हैं कि हमें नए सिरे से बनाए गए मॉक हैंडलर का उपयोग करना है, परीक्षण के तहत आवेदन को कॉल करें, और लाइन 19 में जांचें कि सभी अपेक्षित कॉल किए गए हैं। आप परीक्षण कक्षा में @RunWith(JMock.class) एनोटेशन @RunWith(JMock.class) को जोड़कर उत्तरार्द्ध से छुटकारा पा सकते हैं

EasyMock

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

IMocksControl control = EasyMock.createControl(); @Test public void testSaveWithEasyMock() { final long id = 15; final String data = "cold fusion reactor"; final RequestHandler requestHandler = control.createMock(RequestHandler.class); expect(requestHandler.handle("/upload/" + id, data)).andReturn("Saved " + id); control.replay(); SERVER_HANDLER.setRequestHandler(requestHandler); wayTooComplex.save(id, data); control.verify(); }

पहली पंक्ति में, हम नियंत्रण बनाते हैं, जो जेमॉक संदर्भ का एक एनालॉग है। इसके बाद, आठवीं पंक्ति में, हम एक नकली वस्तु बनाते हैं, दसवीं पंक्ति में हम संकेत देते हैं कि हम कुछ तर्कों के साथ हैंडल विधि के लिए एक कॉल की उम्मीद करते हैं और इस मामले में एक निश्चित मान वापस करने के लिए कहते हैं। यहां विशिष्ट सुरक्षा है : स्ट्रिंग से लेकर रीटर्न के अलावा अन्य प्रकार के एक तर्क को पारित करने का प्रयास एक संकलन त्रुटि के परिणामस्वरूप होगा।
इज़ीमॉक में, मेरे दृष्टिकोण से, अपेक्षित व्यवहार के विनिर्देश अधिक स्पष्ट हैं । यह दृष्टिकोण, हालांकि, एक खामी है: जैसा कि आप पंक्ति 11 में देख सकते हैं, आपको स्पष्ट रूप से संकेत करना चाहिए कि अपेक्षित व्यवहार का रिकॉर्ड समाप्त हो गया है । सभी "व्यावसायिक तर्क" के बाद, हम 17 को लाइन में आते हैं और सत्यापित करते हैं कि सभी अपेक्षित तरीकों को बुलाया गया है। वैसे, अगर हमें परवाह नहीं है कि क्या विधि वापस आती है, तो शून्य तरीकों के लिए हम expect निर्माण को छोड़ सकते हैं और बस एक कॉल कर सकते हैं: requestHandler.handle("/upload/" + id, data) । इसके अलावा, control का उपयोग करना वैकल्पिक है , और आप बस ऐसा कर सकते हैं:

1 2 3 4 5

final RequestHandler requestHandler = EasyMock.createMock(RequestHandler.class); //... EasyMock.replay(requestHandler); //... EasyMock.verify(requestHandler);

विधि आह्वान की अधिक जटिल प्रतिक्रिया

मान लीजिए कि अब हमें परीक्षण करने की आवश्यकता है कि बाहरी घटक के विफल होने पर हमारा अनुप्रयोग सही ढंग से व्यवहार करता है। ऐसा करने के लिए, handle विधि में एक अपवाद को व्यवस्थित करने के लिए पर्याप्त है, और फिर जेटी http की स्थिति 500 ​​को स्वयं निर्धारित करेगा।

JMock

1 2 3 4 5 6 7 8

@Test public void testErrorHandlingWithJMock() { //... context.checking(new Expectations() {{ one(requestHandler).handle("/upload/" + id, data); will(throwException(new RuntimeException("Somebody set up us the bomb."))); }}); }

कुछ भी जटिल नहीं है। मुझे लगता है कि टिप्पणियां बहुत कम हैं। यह जोड़ना संभव है कि returnIterator अभी भी इसे बॉक्स से बाहर करने में सक्षम है, लेकिन आप Action इंटरफ़ेस को लागू करके अपनी व्यवस्था भी कर सकते हैं। सच है, यह बहुत स्पष्ट नहीं है, और प्रलेखन इतना गर्म नहीं है ।

EasyMock

1 2 3 4 5 6

@Test public void testErrorHandlingWithEasyMock() { //... expect(requestHandler.handle("/upload/" + id, data)) .andThrow(new RuntimeException("All your base are belong to us.")); }

यहां सब कुछ भी सरल है, लेकिन, जैसा कि आप शायद पहले से ही संदेह करते हैं, अगर विधि कुछ भी नहीं लौटाती है (यानी शून्य प्रकार है), आपको एक अलग तरीके से लिखना होगा, और शैली की सामान्यता खो गई है । यह इस तरह दिखेगा:

1 2 3 4 5 6

@Test public void testErrorHandlingWithEasyMock() { //... requestHandler.handle("/upload/" + id, data); expectLastCall() .andThrow(new RuntimeException("You have no chance to survive make your time.")); }

andThrow अलावा andThrow आप भी इस्तेमाल कर सकते हैं और andDelegateTo , जो कि आप अनुमान लगा सकते हैं, विधि को किसी अन्य ऑब्जेक्ट पर कॉल करते हैं ( संकलन के दौरान कोई विशिष्ट सुरक्षा नहीं है! ) और andAnswer । उत्तरार्द्ध के लिए, आपको IAnswer इंटरफ़ेस लागू करने की IAnswer है, और answer विधि के अंदर कोई भी कोड लिखें। JMock की तुलना में थोड़ी कम शक्ति है, लेकिन बहुत, बहुत अधिक सुविधा।

किसी विधि को कॉल करते समय तर्कों का मिलान करना

अब मान लीजिए कि हमें पता नहीं है कि मॉकडाउन पद्धति में कॉल करने के लिए कौन से तर्क दिए जाने चाहिए। केवल एक चीज जो हम सुनिश्चित कर रहे हैं वह यह है कि target तर्क में कहीं न कहीं एक id होना चाहिए।

JMock

1 2 3 4 5 6 7

@Test public void testArgumentMatchingWithJMock() { //... context.checking(new Expectations() {{ one(requestHandler).handle(with(containsString(String.valueOf(id))), anything()); }}); }

जेमॉक हैमरेस्ट मैचर्स का उपयोग करता है और यदि आवश्यक हो तो आपको अपने मैचर को लिखने के लिए कुछ गैर-मानक लाठी जोड़ने की अनुमति देता है।

EasyMock

1 2 3 4 5 6

@Test public void testArgumentMatchingWithEasyMock() { //... expect(requestHandler.handle(contains(String.valueOf(id)), anyObject(String.class))) .andReturn(null); }

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

कॉल की गिनती

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

JMock

1 2 3 4 5 6 7

@Test public void testMultipleInvocationsWithJMock() { //... context.checking(new Expectations() {{ between(2, 5).of(requestHandler).handle(anything(), anything()); }}); }

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

EasyMock

1 2 3 4 5 6

@Test public void testMultipleInvocationsWithEasyMock() { //... expect(requestHandler.handle(anyObject(String.class), anyObject(String.class))) .andReturn(null).times(2, 5); }

यहां, भी, सब कुछ काफी सरल है, लेकिन मामूली शून्य है: ऊपर से एक सीमा के बिना "कम से कम एन बार" कहने का कोई तरीका नहीं है । यह देखते हुए थोड़ा अजीब है कि कम से atLeastOnce विधि है। कम से कम तीन कॉल की उम्मीद करने के लिए, आपको इस कोड की तरह कुछ लिखना होगा:

1 2 3 4 5 6 7

@Test public void testMultipleInvocationsWithEasyMock() { //... expect(requestHandler.handle(anyObject(String.class), anyObject(String.class))) .andReturn(null).times(3); expectLastCall().andReturn(null).anyTimes(); }

प्लग

अक्सर ऐसा होता है कि सिद्धांत रूप में यह हमारे लिए बहुत महत्वपूर्ण नहीं है कि कैसे और कब एक विधि कहा जाएगा, लेकिन यह केवल दिलचस्प है कि यह मौजूद है और कुछ लौटाता है।

JMock

1 2 3 4 5 6 7 8

@Test public void testStubMethodsWithJMock() { //... context.checking(new Expectations() {{ allowing(requestHandler).handle(anything(), anything()); will(returnValue("There will be cake")); }}); }

यह ध्यान देने योग्य है कि यह उसी तरह से किया जाता है जैसे समय की संख्या का निर्धारण। allowing बजाय allowing आप ignoring कर सकते हैं। इसके अलावा, यदि आप चाहें, तो पूरे मॉक ऑब्जेक्ट को एक बड़े स्टब के साथ बनाना आसान है:

1 2 3 4 5 6 7

@Test public void testStubObjectsWithJMock() { //... context.checking(new Expectations() {{ allowing(requestHandler); }}); }

EasyMock

1 2 3 4 5 6

@Test public void testStubMethodsWithEasyMock() { //... expect(requestHandler.handle(anyObject(String.class), anyObject(String.class))) .andStubReturn("Greetings, human."); }

शैली में थोड़ा कम समान, लेकिन यह भी काफी आरामदायक है। लेकिन आप केवल एक वस्तु बना सकते हैं जब एक गाग बनाते हैं:

1 2 3 4 5

@Test public void testStubObjectsWithEasyMock() { final RequestHandler requestHandler = createNiceMock(RequestHandler.class); //... }

विधियाँ, जब कहा जाता है, उनके प्रकार ( 0 , false या null ) के लिए डिफ़ॉल्ट मान लौटाएगा। String लिए सहित, वापस आ जाएगा , जबकि इस वर्ग के लिए JMock में, डिफ़ॉल्ट मान एक रिक्त स्ट्रिंग है।

विधि कॉल आदेश की जाँच करना

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

JMock

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

@Test public void testStrictOrderingWithJMock() { //... final Sequence paranoia = context.sequence("shhh-they-are-watching-us"); context.checking(new Expectations() {{ one(requestHandler).handle("/upload/" + id, data); will(returnValue("Saved " + id)); inSequence(paranoia); one(requestHandler).handle("/get/" + id, ""); will(returnValue(data)); inSequence(paranoia); }}); }

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

EasyMock

1 2 3 4 5 6 7

@Test public void testStrictOrderingWithEasyMock() { //... EasyMock.checkOrder(requestHandler, true); EasyMock.expect(requestHandler.handle("/upload/" + id, data)).andReturn("Saved " + id); EasyMock.expect(requestHandler.handle("/get/" + id, "")).andReturn(data); }

यहां सब कुछ कुछ सरल है: व्यक्तिगत रूप से प्रत्येक मॉक के लिए परीक्षण को कई बार चालू और बंद किया जा सकता है । इसके अलावा, पूरा control सख्त हो सकता है (पहला उदाहरण देखें), और फिर इसमें शामिल सभी मोक्स के लिए सामान्य आदेश की जांच की जाएगी। इसके अलावा, नकली या नियंत्रण को createStrictMock कहकर निर्माण पर तुरंत सख्त किया जा सकता है । बेशक, हरे रंग की ऐसी मात्रा को एक गंभीर माइनस के साथ पतला होना चाहिए: एक मोक (या नियंत्रण) कई दृश्यों में भाग नहीं ले सकता है । यहां तक ​​कि ऐसी कोई बात भी नहीं है।

ऐसी शर्तें जिनके तहत एक विधि कॉल की अनुमति है

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

JMock

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

@Test public void testStatesWithJMock() { //... final States progress = context.states("progress").startsAs("none"); context.checking(new Expectations() {{ one(requestHandler).handle("/panola/upload/" + id, data); will(returnValue("Saved " + id)); when(progress.is("none")); then(progress.is("panola")); one(requestHandler).handle("/yarbo/upload/" + id, data); will(returnValue("Saved " + id)); when(progress.is("none")); then(progress.is("yarbo")); one(requestHandler).handle("/panola/get/" + id, ""); will(returnValue(data)); when(progress.is("panola")); then(progress.is("done")); one(requestHandler).handle("/yarbo/get/" + id, ""); will(returnValue(data)); when(progress.is("yarbo")); then(progress.is("done")); }}); }

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

ईज़ीमॉक: नो एनालॉग

मल्टी-थ्रेडेड कोड टेस्टिंग

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

JMock

ईमानदारी से, मेरे लिए यह एक भयानक पीड़ा थी: इस मुद्दे पर प्रलेखन (जैसा कि, संयोग से, कई अन्य लोगों पर) बहुत आलंकारिक है, और इसलिए मुझे परीक्षण और त्रुटि (और तब से मैं एम्स्टर्डम में था, और हवाई अड्डे पर भी अभिनय करना पड़ा था) , यह इतना आसान नहीं था) । परिणामस्वरूप, मैं JMock 2.6.0-RC2 के मैन्युअल रूप से डाउनलोड किए गए संस्करण हैमरेस्ट-कोर 1.3.0RC1 और निम्नलिखित कोड के मैन्युअल रूप से डाउनलोड किए गए संस्करण द्वारा सहेजा गया था:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

private Synchroniser synchroniser = new Synchroniser(); private Mockery context = new JUnit4Mockery() {{ this.setThreadingPolicy(synchroniser); }}; @Test public void testConcurrencyWithJMock() { //... final States progress = context.states("progress").startsAs("none"); context.checking(new Expectations() {{ //check something then(progress.is("done")); }}); //do something in multiple threads synchroniser.waitUntil(states.is("done"), TimeUnit.SECONDS.toMillis(1)); }

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

EasyMock

बॉक्स के बाहर मल्टीथ्रेडिंग के लिए पूर्ण समर्थन है। इसके अलावा, आप रिकॉर्डिंग के दौरान makeThreadSafe(mock, false) का उपयोग करके इसे अक्षम कर सकते हैं , और यदि आवश्यक हो, तो सत्यापित करें कि checkIsUsedInOneThread(mock, true) कहकर एक धागे से नकली का उपयोग किया गया था।

मॉकिंग क्लासेस

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

JMock

1 2 3 4 5 6 7 8

private Mockery context = new JUnit4Mockery() {{ this.setImposteriser(ClassImposteriser.INSTANCE); }}; @Test public void testClassMockingWithJMock() { //... }

आपको बस इतना करना है कि संदर्भ पर setImposteriser विधि को कॉल करें। उदाहरण में, यह दूसरी पंक्ति पर होता है।

EasyMock

1 2 3 4 5 6

import static org.easymock.classextension.EasyMock.*; @Test public void testClassMockingWithEasyMock() { //... }

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

आंशिक उपहास

फिर भी कभी-कभी यह केवल कक्षा के तरीकों के हिस्से पर मॉक बनाने के लिए आवश्यक हो सकता है, बाकी को छूने के बिना।

JMock: ऐसा कोई अवसर नहीं

EasyMock

1 2 3 4 5 6 7

@Test public void testPartialMockingWithEasyMock() { //... IntArraySorter sorter = EasyMock.createMockBuilder(IntArraySorter.class) .addMockedMethod("sort", int[].class).createMock(); //... }

सब कुछ सरल और स्पष्ट है। आप यह भी निर्दिष्ट कर सकते हैं कि किस निर्माता को पास करना है। सभी गैर-नकली तरीकों को इस वर्ग को सौंप दिया जाएगा।

निष्कर्ष

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

शायद पाठक मुझसे इस सवाल के जवाब की प्रतीक्षा कर रहा है कि "मुझे अपनी परियोजना में क्या उपयोग करना चाहिए?" JMock या EasyMock? " यहाँ उत्तर बहुत सरल और स्पष्ट है: “परियोजना की आवश्यकताओं पर निर्भर करता है। इन पुस्तकालयों में से प्रत्येक एक उपकरण है, और उनमें से प्रत्येक का उपयोग करने में सक्षम होने की आवश्यकता है, और आपको एक विशिष्ट कार्य के लिए उनमें से एक को चुनने की आवश्यकता है। "

वह सब है। दिलचस्प सवालों और टिप्पणियों की प्रतीक्षा है!