मॉक एक बैसाखी नहीं है, नकली एक विनिर्देश है

TDDs की परिक्रमा करने वाले कई छद्म-आईडी के बीच, टेस्ट डबल्स के लिए कुछ अवहेलना है, कम से कम उनके हास्यास्पद नामों से संबंधित नहीं है।

वे उन्हें किसी भी तरह गर्व से कहते हैं, अन्यथा मोक, ठूंठ, नकली - एक भावना जो हम वास्तव में कुछ भी नहीं खोते हैं अगर हम इसका उपयोग नहीं करते हैं। ("एकीकरण परीक्षण" और "वास्तविक निर्भरता" के विपरीत)।

हालाँकि, आप दृष्टिकोण बदल सकते हैं। अंत में, मॉक न केवल इतना और न ही निर्भर घटक का समर्थन करता है, बल्कि निर्भरता के व्यवहार को निर्दिष्ट करता है। और "वास्तविक" कार्यान्वयन एक निश्चित वर्तमान है, संभवतः हमारे गर्व के विचार का गलत अवतार है।

इस अर्थ में, हर बार जब हम लिखते हैं

when(mockDependency.method(inputValue)).thenReturn(returnValue) ,

हम कुछ घटक व्यवहार का दस्तावेजीकरण करते हैं।

इसलिए कई परिणाम हैं।

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

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

इस प्रकार, स्क्रिप्ट क्लासेस ValidOrderProviderStub, ExpiredOrderProviderStub, InvalidOrderIdException_OrderProviderStub, OnlyOnceOrderProvider और इसी तरह, जो एक ही पैकेज में हो सकता है और एक ही बार में सभी परीक्षणों द्वारा उपयोग किया जाता है, प्रत्येक OrderProvider वर्ग में जोड़े जाते हैं।

इसमें स्पाई कक्षाएं शामिल हैं जो अपने आप को लागू करना आसान हैं।

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

इस प्रकार, कोड को पढ़ते समय, हम एक सम्मेलन कर सकते हैं कि मोक की उपस्थिति एक स्क्रिप्ट की संभावना की पुष्टि करती है, और इसकी अनुपस्थिति इस तरह की स्क्रिप्ट के अस्तित्व को प्रतिबंधित करती है। यदि हम ग्राहक वर्गों को मॉकिटो उम्मीदों को लिखने से मना करते हैं, तो NullOrderProvider की तलाश में यह पता चलता है कि कोई उपयुक्त नकली नहीं है, क्योंकि अशक्त कभी नहीं लौटता है, और इसलिए इस परिदृश्य के लिए परीक्षण करने का कोई मतलब नहीं है।

यदि मोक एक विनिर्देश है, तो मोक एक घटक के लिए हमारी योजनाओं का प्रतिबिंब है, और उन्हें कार्यान्वयन के आगे लिखा जाना चाहिए।

यदि एक मोक एक विनिर्देश है, तो यह पदानुक्रमित है और कुछ शर्तों के आधार पर घटक के व्यवहार को दर्शाता है।

इस प्रकार, हमारी मोकी बहुत अधिक बढ़ सकती है: बिना शर्त वाली मोकी हमेशा वही लौटाती है, साथ ही आंतरिक स्थिति के साथ मोकी भी, जैसे कि forIdOne_returningOne_forIdTwo_ReturnorTwo_OrderProvider। अंतिम गणना और आपको उचित व्यवहार के साथ एक FakeOrderProvider बनाने की आवश्यकता है, जिसे वास्तविक कार्यान्वयन के साथ सिंक्रनाइज़ किया जाना चाहिए।

तदनुसार, यदि कोई मोक एक निश्चित व्यवहार का एक विनिर्देश है, तो एक घटक का कार्यान्वयन उसके मोक्स के साथ एक घटक के व्यवहार को सिंक्रनाइज़ करने से ज्यादा कुछ नहीं है।

और यह, शायद, मॉब के खिलाफ मुख्य तर्क है - वर्तमान वास्तविक कार्यान्वयन के साथ उनके व्यवहार को सिंक्रनाइज़ करने की आवश्यकता है, हम अगली बार इसके बारे में अलग से बात करेंगे।