यूनिट टेस्ट एब्सट्रैक्ट क्लासेस कैसे करें: स्टब्स के साथ विस्तार करें?

Question

मैं सोच रहा था कि अमूर्त कक्षाएं, और अमूर्त कक्षाओं का विस्तार करने वाली कक्षाओं का परीक्षण कैसे किया जाए।

क्या मुझे अमूर्त वर्ग का परीक्षण करना चाहिए, अमूर्त विधियों को बताते हुए, और फिर सभी ठोस तरीकों का परीक्षण करना चाहिए? फिर केवल उन विधियों का परीक्षण करता हूं जिन्हें मैं ओवरराइड करता हूं, और उन वस्तुओं के लिए यूनिट परीक्षणों में सार विधियों का परीक्षण करता हूं जो मेरे अमूर्त वर्ग का विस्तार करते हैं?

क्या मेरे पास एक अमूर्त परीक्षण का मामला होना चाहिए जो अमूर्त वर्ग के तरीकों का परीक्षण करने के लिए इस्तेमाल किया जा सकता है, और इस वर्ग को अपने परीक्षण के मामले में उन वस्तुओं के लिए विस्तारित करना है जो अमूर्त वर्ग का विस्तार करते हैं?

ध्यान दें कि मेरे सार वर्ग में कुछ ठोस तरीके हैं।

Answer 1

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

आपको अमूर्त वर्ग का परीक्षण करना चाहिए जिसमें आपके पास अन्य सभी वर्गों की तरह कुछ तर्क होते हैं।

Comments

अरे, मुझे कहना है कि यह पहली बार है जब मैंने कभी मॉक के उपयोग के विचार से सहमति व्यक्त की है।

— जोनाथन एलन

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

— साइबर-भिक्षु

यह स्पष्ट रूप से ऐसा करना संभव है .. लेकिन वास्तव में किसी भी व्युत्पन्न वर्ग का परीक्षण करने के लिए आप इस आधार कार्यक्षमता को बार-बार परीक्षण कर रहे हैं .. जो आपको एक अमूर्त परीक्षा स्थिरता प्रदान करता है ताकि आप परीक्षण में इस दोहराव को समाप्त कर सकें। यह सब बदबू आ रही है! मैं दृढ़ता से एक और नज़र लेने की सलाह देता हूं कि आप पहली जगह में अमूर्त कक्षाओं का उपयोग क्यों कर रहे हैं और देखें कि क्या कुछ और बेहतर काम करेगा।

— निगेल थॉर्न

ओवर-रटा हुआ अगला उत्तर ज्यादा बेहतर है।

— मार्टिन स्पामेर

@MartiSpamer: मैं यह नहीं कहूंगा कि यह उत्तर अति-मूल्यांकित है क्योंकि यह उत्तर (2 वर्ष) बहुत पहले लिखा गया था। आइए सिर्फ पैट्रिक को प्रोत्साहित करें क्योंकि जब उन्होंने इस उत्तर को पोस्ट किया, तो यह बहुत अच्छा था। एक दूसरे को प्रोत्साहित करते हैं। चीयर्स

— मार्विन थोबजाने

Answer 2

दो तरीके हैं जिनमें अमूर्त आधार वर्गों का उपयोग किया जाता है।

1. आप अपनी सार वस्तु को विशेषज्ञता दे रहे हैं, लेकिन सभी ग्राहक इसके आधार इंटरफेस के माध्यम से व्युत्पन्न वर्ग का उपयोग करेंगे।

2. आप अपने डिजाइन में वस्तुओं के भीतर दोहराव को समाप्त करने के लिए एक सार आधार वर्ग का उपयोग कर रहे हैं, और ग्राहक अपने स्वयं के इंटरफेस के माध्यम से ठोस कार्यान्वयन का उपयोग करते हैं।

---

1 के लिए समाधान - रणनीति पैटर्न

यदि आपके पास पहली स्थिति है, तो आपके पास वास्तव में सार वर्ग में आभासी विधियों द्वारा परिभाषित एक इंटरफ़ेस है जिसे आपके व्युत्पन्न वर्ग कार्यान्वित कर रहे हैं।

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

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

---

2 के लिए समाधान

यदि आपके पास दूसरी स्थिति है, तो आपका अमूर्त वर्ग सहायक वर्ग के रूप में काम कर रहा है।

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

यह फिर से ठोस वर्गों की ओर जाता है जो सरल और आसानी से परीक्षण योग्य हैं।

---

यथाविधि

जटिल वस्तुओं के एक सरल नेटवर्क पर सरल वस्तुओं के अनुकूल जटिल नेटवर्क।

एक्स्टेंसिबल टेस्टेबल कोड की कुंजी छोटे बिल्डिंग ब्लॉक और स्वतंत्र वायरिंग है।

---

अपडेट किया गया: दोनों के मिश्रण को कैसे संभालें?

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

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

---

अपडेट 2: स्टेपिंग स्टोन के रूप में एब्सट्रैक्ट क्लासेस (2014/06/12)

मेरे पास दूसरे दिन एक स्थिति थी जहां मैंने सार का उपयोग किया, इसलिए मैं यह जानना चाहूंगा कि क्यों।

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

मैंने इसे अमूर्त आधार वर्ग के रूप में लागू किया है जो जानता है कि सेटिंग्स फ़ाइलों को पार्स कैसे किया जाता है और व्युत्पन्न वर्ग उन समान विधियों को उजागर करते हैं, लेकिन सेटिंग्स फ़ाइल के स्थान को समझाया।

मैं एक "SettingsFileParser" लिख सकता था कि 3 कक्षाएं लिपटे, और फिर डेटा एक्सेस विधियों को उजागर करने के लिए बेस क्लास के माध्यम से प्रत्यायोजित किया गया। मैंने अभी तक ऐसा नहीं करने का फैसला किया क्योंकि इससे 3 से अधिक वर्गों का प्रतिनिधित्व होगा, जिसमें कुछ भी नहीं था।

हालाँकि ... जैसा कि यह कोड विकसित होता है और इनमें से प्रत्येक सेटिंग वर्ग के उपभोक्ता स्पष्ट हो जाते हैं। प्रत्येक सेटिंग्स उपयोगकर्ता कुछ सेटिंग्स के लिए पूछेंगे और उन्हें किसी तरह से रूपांतरित करेंगे (जैसा कि सेटिंग्स पाठ हैं वे उन्हें संख्याओं आदि में परिवर्तित करने की वस्तुओं में लपेट सकते हैं)। जैसा कि ऐसा होता है, मैं इस तर्क को डेटा हेरफेर विधियों में निकालना शुरू करूंगा और उन्हें जोरदार टाइप की गई सेटिंग्स कक्षाओं में वापस धकेल दूंगा। यह सेटिंग्स के प्रत्येक सेट के लिए एक उच्च स्तरीय इंटरफ़ेस को जन्म देगा, जो कि अंततः 'सेटिंग' के साथ काम कर रहा है।

इस बिंदु पर दृढ़ता से टाइप की गई सेटिंग्स कक्षाएं अब "गेट्टर" विधियों की आवश्यकता नहीं होंगी जो अंतर्निहित 'सेटिंग' कार्यान्वयन को उजागर करती हैं।

उस बिंदु पर मैं अब उनके सार्वजनिक इंटरफ़ेस को सेटिंग्स एक्सेसर विधियों में शामिल नहीं करना चाहूंगा; इसलिए मैं इस वर्ग को इसे से प्राप्त करने के बजाय एक सेटिंग पार्सर वर्ग को इनकैप्सुलेट करने के लिए बदल दूंगा।

अमूर्त वर्ग इसलिए है: मेरे लिए इस समय प्रतिनिधिमंडल कोड से बचने का एक तरीका है, और कोड में एक मार्कर मुझे डिजाइन को बाद में बदलने के लिए याद दिलाने के लिए है। मुझे यह कभी नहीं मिल सकता है, इसलिए यह एक अच्छा समय हो सकता है ... केवल कोड ही बता सकता है।

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

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

Comments

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

— मैल्कम टकर

मैं इस पर वास्तव में कितना अच्छा जवाब दे सकता हूं। यह सार वर्गों के बारे में सोचने के मेरे तरीके को पूरी तरह से बदल दिया है। धन्यवाद निगेल।

— MalcomTucker

अरे नहीं .. एक और सिद्धांत मैं पुनर्विचार करने के लिए गोंग हूँ! धन्यवाद (दोनों के लिए व्यंग्यात्मक रूप से अभी के लिए, और गैर-व्यंग्यात्मक रूप से एक बार के लिए मैंने इसे आत्मसात कर लिया है और एक बेहतर प्रोग्रामर की तरह महसूस करता हूं)

— मार्टिन लिन

अच्छा उत्तर। निश्चित रूप से कुछ सोचने के लिए ... लेकिन क्या आप मूल रूप से अमूर्त वर्गों का उपयोग नहीं करने के लिए कह रहे हैं?

— ब्रायनस्टी

अकेले नियम के लिए +1, "जटिल वस्तुओं के एक सरल नेटवर्क पर सरल वस्तुओं के अनुकूल जटिल नेटवर्क।"

— डेविड ग्लास

Answer 3

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

Comments

यह उपवर्ग में कास्टिंग मुद्दों का कारण नहीं है? अगर X में विधि a और Y है तो X को विरासत में मिला है लेकिन एक विधि b भी है। जब आप अपने परीक्षण वर्ग को उपवर्ग में रखते हैं, तो आपको b पर परीक्षण करने के लिए अपने अमूर्त चर को Y पर नहीं डालना पड़ेगा?

— जॉननो नोलन

Answer 4

विशेष रूप से अमूर्त वर्ग पर एक इकाई परीक्षण करने के लिए, आपको इसे परीक्षण के उद्देश्य से प्राप्त करना चाहिए, इनहेरिट करते समय बेसमिथोड () परिणामों और इच्छित व्यवहार का परीक्षण करें।

आप इसे कॉल करके एक विधि का परीक्षण करते हैं इसलिए इसे लागू करके एक सार वर्ग का परीक्षण करें ...

Answer 5

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

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

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

Answer 6

एक तरीका यह है कि एक अमूर्त परीक्षा का मामला लिखा जाए जो आपके सार वर्ग से मेल खाता हो, फिर ठोस परीक्षण मामलों को लिखें जो आपके सारगर्भित मामले को उप-वर्ग बनाते हैं। अपने मूल अमूर्त वर्ग (यानी आपके परीक्षण मामले पदानुक्रम अपनी कक्षा पदानुक्रम को प्रतिबिंबित करता है) के प्रत्येक ठोस उपवर्ग के लिए ऐसा करें। देखें कनिष्ठ प्राप्तकर्ता पुस्तक में एक परीक्षण देखें: http://safari.informit.com/9781932394238/ch02lev1sec6 ।

एक्सकेस पैटर्न में टेस्टकेस सुपरक्लास भी देखें: http://xunitpatterns.com/Testcase%20Superclass.html

Answer 7

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

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

Comments

मैं यह नहीं चाहता था कि मैं पहले से ही टेस्ट कर चुका था कि मैं टेस्ट टेस्ट केस रोड पर क्यों जा रहा हूं। मैं अपने अमूर्त वर्ग के सभी ठोस तरीकों को एक ही जगह पर परखने की कोशिश कर रहा हूँ।

— पॉल व्हेलन

मैं सामान्य तत्वों को सहायक वर्गों में निकालने से असहमत हूं, कम से कम कुछ (कई?) मामलों में। यदि एक अमूर्त वर्ग में कुछ ठोस कार्यक्षमता है, तो मुझे लगता है कि यह सीधे इकाई परीक्षण के लिए पूरी तरह स्वीकार्य है।

— सेठ पेट्री-जॉनसन

Answer 8

यह वह पैटर्न है जो मैं आमतौर पर अमूर्त वर्ग के परीक्षण के लिए एक सामंजस्य स्थापित करते समय अपनाता हूं:

public abstract class MyBase{
  /*...*/
  public abstract void VoidMethod(object param1);
  public abstract object MethodWithReturn(object param1);
  /*,,,*/
}

और संस्करण मैं परीक्षण के तहत उपयोग:

public class MyBaseHarness : MyBase{
  /*...*/
  public Action<object> VoidMethodFunction;
  public override void VoidMethod(object param1){
    VoidMethodFunction(param1);
  }
  public Func<object, object> MethodWithReturnFunction;
  public override object MethodWithReturn(object param1){
    return MethodWihtReturnFunction(param1);
  }
  /*,,,*/
}

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

Answer 9

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

Answer 10

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

Answer 11

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

एक इकाई परीक्षण के दृष्टिकोण से, विचार करने के लिए दो चीजें हैं:

1. इससे संबंधित कक्षाओं के साथ आपके अमूर्त वर्ग की सहभागिता । मॉक टेस्टिंग फ्रेमवर्क का उपयोग करना इस परिदृश्य के लिए आदर्श है क्योंकि यह दर्शाता है कि आपका सार वर्ग दूसरों के साथ अच्छा खेलता है।

2. व्युत्पन्न वर्गों की कार्यक्षमता । यदि आपके पास कस्टम तर्क हैं जो आपने अपनी व्युत्पन्न कक्षाओं के लिए लिखे हैं, तो आपको उन वर्गों को अलगाव में परीक्षण करना चाहिए।

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

Answer 12

पहले अगर अमूर्त वर्ग में कुछ ठोस तरीका होता है, तो मुझे लगता है कि आपको इस उदाहरण पर विचार करना चाहिए

 public abstract class A 

 {

    public boolean method 1
    {
        // concrete method which we have to test.

    }


 }


 class B extends class A

 {

      @override
      public boolean method 1
      {
        // override same method as above.

      }


 } 


  class Test_A 

  {

    private static B b;  // reference object of the class B

    @Before
    public void init()

      {

      b = new B ();    

      }

     @Test
     public void Test_method 1

       {

       b.method 1; // use some assertion statements.

       }

   }

Answer 13

यदि एक अमूर्त वर्ग आपके कार्यान्वयन के लिए उपयुक्त है, तो परीक्षण (जैसा कि ऊपर सुझाव दिया गया है) एक व्युत्पन्न ठोस वर्ग। आपकी धारणाएँ सही हैं।

भविष्य की उलझन से बचने के लिए, ध्यान रखें कि यह ठोस परीक्षण वर्ग नकली नहीं है, बल्कि नकली है ।

सख्त शब्दों में, एक मॉक निम्न विशेषताओं द्वारा परिभाषित किया गया है:

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

Answer 14

@ Patrick-desjardins उत्तर के बाद, मैंने सार लागू किया और यह कार्यान्वयन वर्ग के साथ-साथ @Testनिम्नानुसार है:

सार वर्ग - ABC.java

import java.util.ArrayList;
import java.util.List;

public abstract class ABC {

    abstract String sayHello();

    public List<String> getList() {
        final List<String> defaultList = new ArrayList<>();
        defaultList.add("abstract class");
        return defaultList;
    }
}

जैसा कि सार वर्गों को त्वरित नहीं किया जा सकता है, लेकिन उन्हें उपवर्गित किया जा सकता है , ठोस वर्ग DEF.java , इस प्रकार है:

public class DEF extends ABC {

    @Override
    public String sayHello() {
        return "Hello!";
    }
}

@ सबसे अमूर्त और गैर-अमूर्त विधि दोनों का परीक्षण करने के लिए उत्तम श्रेणी:

import org.junit.Before;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.empty;
import static org.hamcrest.Matchers.is;
import static org.hamcrest.Matchers.not;
import static org.hamcrest.Matchers.contains;
import java.util.Collection;
import java.util.List;
import static org.hamcrest.Matchers.equalTo;

import org.junit.Test;

public class DEFTest {

    private DEF def;

    @Before
    public void setup() {
        def = new DEF();
    }

    @Test
    public void add(){
        String result = def.sayHello();
        assertThat(result, is(equalTo("Hello!")));
    }

    @Test
    public void getList(){
        List<String> result = def.getList();
        assertThat((Collection<String>) result, is(not(empty())));
        assertThat(result, contains("abstract class"));
    }
}