वास्तविक कार्यान्वयन के साथ नकली सिंक्रनाइज़ेशन

जब भी परीक्षण रणनीतियों पर चर्चा की जाती है, तो सिंक्रनाइज़ेशन समस्या उत्पन्न होती है। मूल रूप से - अतिरिक्त लोड के कारण जो मोक डेवलपर्स के लिए बनाते हैं और वास्तविक निर्भरता से निकलने वाले मूक के जोखिम भी।

तो, वास्तविक कार्यान्वयन के साथ मोक के तुल्यकालन को सुनिश्चित करना हमारे लिए किस तरह से सस्ता है?

सिंक्रनाइज़ेशन के लिए, हम एक परीक्षण लिख सकते हैं जो मोक और वास्तविक कार्यान्वयन के खिलाफ समान जांच करता है।

यह कुछ ऐसा दिखता है (मैं DI के बिना लिखता हूं, लेकिन DI के साथ यह आसान और अधिक सही है):

public abstract class AbstractValidOrderDaoTest(){ Dao dao; public abstract arrange(); @Test public void whenValidOrderInDb_thenReturnValidOrder(){ arrange(); Order order = dao.retrieve(); assertNotNull(order); assertNotNull(order.getCustomerName()); //    } } public class ValidOrderDaoTest extends AbstractOrderDaoTest(){ @Override public void arrange(){ dao = new FakeValidOrderDao(); } } public class OrderDaoTest extends AbstractOrderDaoTest(){ @Override public void arrange(){ dao = new RealOrderDao(new ValidOrderDataSource(url, user, pwd)); } } 

ऑर्डरडाउटेस्ट एक अंतर्निहित मॉक या वास्तविक निर्भरता के साथ एक वास्तविक वस्तु के खिलाफ काम करता है, और वैलिडरऑडरडैस्ट एक मॉक के खिलाफ काम करता है।

यदि ValidOrderDataSource एक वास्तविक डेटाबेस है, तो ऑर्डरडाउटेस्ट एक अलग पैकेज में होगा और एकीकरण परीक्षणों के भाग के रूप में चलाया जाएगा, जो डेटाबेस को अपडेट करते समय समय-समय पर दुर्घटनाग्रस्त हो सकता है, उदाहरण के लिए। यह CI \ CD के साथ हस्तक्षेप नहीं करना चाहिए।

यदि ValidOrderDataSource एक मॉक डेटाबेस है, तो ऑर्डरडैओटेस्ट बाकी यूनिट परीक्षणों के साथ चलेगा।

चूंकि मॉक सिंक्रोनाइज़ेशन में वास्तविक वर्ग का परीक्षण करना शामिल है, फिर इसके लिए
वास्तविक वर्ग को अपनी अंतर्निहित निर्भरता को कमज़ोर करना होगा। इसके अलावा, अंतर्निहित मोक-नशे की लत को मोकिंग के परिदृश्य के अनुसार व्यवहार करना चाहिए। हमारे मामले में, यह
ValidOrderDataSource।

यदि आप इसके बारे में सोचते हैं, तो यह समझ में आता है - उच्च वर्गों के व्यवहार के बारे में कोई भी बयान अंतर्निहित लोगों में कुछ परिदृश्य का तात्पर्य करता है। यदि नियंत्रक सेवा से कुछ देता है, तो यह अच्छा होगा यदि आधार इसे प्रदान कर सकता है।

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

पुनरावृत्ति से पता चलता है कि शीर्ष-स्तरीय मॉक को सिंक्रनाइज़ करने के लिए, आपको बाहरी निर्भरता तक सभी अंतर्निहित नकली का सिंक्रनाइज़ेशन शुरू करने की आवश्यकता है।

यह सिस्टम विनिर्देश को और अधिक पारदर्शी बनाता है, क्योंकि अधिक सामान्य और सार परिदृश्य अधिक निजी लोगों पर भरोसा करते हैं।

यह भी ध्यान दें कि मोक हैं जिन्हें सिंक्रनाइज़ करने की आवश्यकता नहीं है। यानी हमारे पास ऐसा कोई वास्तविक कार्यान्वयन नहीं है जिसे क्रॉस-परीक्षण करने की आवश्यकता हो। यह प्रमुख त्रुटि परिदृश्यों पर लागू होता है। EmptyResultException_Datasource उदा। यह आवश्यक क्रॉस-टेस्ट की संख्या को बहुत कम कर देता है।

सिंक्रनाइज़ेशन निश्चित रूप से वास्तविक बाहरी निर्भरता, जैसे कि कतार, बाहरी सेवाओं, डेटाबेस - की आवश्यकता होती है - विशेष रूप से उस डेटा के संबंध में जो वे लेते हैं और वापस लौटते हैं।

यदि बाहरी सेवा अचानक बदल जाती है, जो अक्सर विकास के चरण में होती है, तो हमारे पास अपने व्यवहार की जांच करने का कोई तरीका नहीं है यदि हम एक सिंक्रनाइज़ेशन टेस्ट नहीं लिखते हैं।

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

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