मैं इन ढांचे की परीक्षण पठनीयता, आकार या परीक्षण तकनीकों के बारे में बहस नहीं करूंगा, मेरा मानना है कि वे बराबर हैं, लेकिन एक साधारण उदाहरण पर मैं आपको अंतर दिखाऊंगा।
को देखते हुए: हम एक वर्ग जो कहीं कुछ संचय के लिए जिम्मेदार है:
public class Service {
public static final String PATH = "path";
public static final String NAME = "name";
public static final String CONTENT = "content";
private FileDao dao;
public void doSomething() {
dao.store(PATH, NAME, IOUtils.toInputStream(CONTENT));
}
public void setDao(FileDao dao) {
this.dao = dao;
}
}
और हम इसे परीक्षण करना चाहते हैं:
Mockito:
public class ServiceMockitoTest {
private Service service;
@Mock
private FileDao dao;
@Before
public void setUp() {
MockitoAnnotations.initMocks(this);
service = new Service();
service.setDao(dao);
}
@Test
public void testDoSomething() throws Exception {
// given
// when
service.doSomething();
// then
ArgumentCaptor<InputStream> captor = ArgumentCaptor.forClass(InputStream.class);
Mockito.verify(dao, times(1)).store(eq(Service.PATH), eq(Service.NAME), captor.capture());
assertThat(Service.CONTENT, is(IOUtils.toString(captor.getValue())));
}
}
EasyMock:
public class ServiceEasyMockTest {
private Service service;
private FileDao dao;
@Before
public void setUp() {
dao = EasyMock.createNiceMock(FileDao.class);
service = new Service();
service.setDao(dao);
}
@Test
public void testDoSomething() throws Exception {
// given
Capture<InputStream> captured = new Capture<InputStream>();
dao.store(eq(Service.PATH), eq(Service.NAME), capture(captured));
replay(dao);
// when
service.doSomething();
// then
assertThat(Service.CONTENT, is(IOUtils.toString(captured.getValue())));
verify(dao);
}
}
जैसा कि आप देख सकते हैं कि दोनों टेस्ट काफी समान हैं और उनमें से दोनों गुजर रहे हैं। अब, कल्पना करें कि किसी और ने सेवा कार्यान्वयन और परीक्षण चलाने की कोशिश की है।
नया सेवा कार्यान्वयन:
dao.store(PATH + separator, NAME, IOUtils.toInputStream(CONTENT));
विभाजक पथ के अंत लगातार
पर जोड़ा गया है कैसे परीक्षण परिणाम अभी कैसे दिखेंगे? सभी दोनों परीक्षणों के पहले असफल हो जायेगी, लेकिन अलग त्रुटि संदेश के साथ:
EasyMock:
java.lang.AssertionError: Nothing captured yet
at org.easymock.Capture.getValue(Capture.java:78)
at ServiceEasyMockTest.testDoSomething(ServiceEasyMockTest.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
Mockito:
Argument(s) are different! Wanted:
dao.store(
"path",
"name",
<Capturing argument>
);
-> at ServiceMockitoTest.testDoSomething(ServiceMockitoTest.java:34)
Actual invocation has different arguments:
dao.store(
"path\",
"name",
[email protected]
);
-> at Service.doSomething(Service.java:13)
EasyMock परीक्षा में क्या हुआ, क्यों परिणाम पर कब्जा कर लिया नहीं किया गया था? क्या स्टोर विधि निष्पादित नहीं की गई थी, लेकिन एक मिनट प्रतीक्षा करें, यह क्यों था, EasyMock हमसे क्यों झूठ बोलता है?
ऐसा इसलिए है क्योंकि EasyMock एक पंक्ति में दो जिम्मेदारियों को मिलाकर - स्टबिंग और सत्यापन। यही कारण है कि जब कुछ गलत होता है तो यह समझना मुश्किल होता है कि कौन सा हिस्सा विफलता पैदा कर रहा है।
बेशक आप मुझे बता सकते हैं - बस परीक्षण को बदलें और दावा से पहले सत्यापित करें। वाह, क्या आप गंभीर हैं, डेवलपर्स को फ्रेमवर्क का मज़ाक उड़ाकर कुछ जादू आदेश को ध्यान में रखना चाहिए?
वैसे, यह मदद नहीं करेगा:
java.lang.AssertionError:
Expectation failure on verify:
store("path", "name", capture(Nothing captured yet)): expected: 1, actual: 0
at org.easymock.internal.MocksControl.verify(MocksControl.java:111)
at org.easymock.classextension.EasyMock.verify(EasyMock.java:211)
फिर भी, यह कह रहा है मुझे लगता है कि विधि क्रियान्वित नहीं था, लेकिन यह था केवल एक और मानकों के साथ।
क्यों मॉकिटो बेहतर है? यह ढांचा एक ही स्थान पर दो जिम्मेदारियों को मिश्रित नहीं करता है और जब आपके परीक्षण विफल हो जाएंगे, तो आप आसानी से समझेंगे क्यों।
हाँ, मैं सोच कर दिया गया है एक ही: Mockito (और Unitils नकली, एक ऐसी ही मजाक एपीआई) के साथ यह बहुत परीक्षण है कि खुशी से जब वे नहीं करना चाहिए पारित करने के लिए जारी रखने के लिए लिखने के लिए आसान है। मुझे संदेह है कि यह मुख्य कारण हो सकता है कि मॉकिटो-जैसी एपीआई, जो अत्यधिक "ढीले" परीक्षणों के निर्माण को सुविधाजनक बनाती है, को अक्सर "आसान" माना जाता है। –
मुझे एक उदाहरण देखने में दिलचस्पी होगी जो इन 2 दृष्टिकोणों से विरोधाभास करता है ... – Armand