कक्षाएं जो अन्य वर्गों (सदस्यों के रूप में, या विधियों के तर्क के रूप में) का उपयोग करती हैं, उन उदाहरणों की आवश्यकता होती है जो इकाई परीक्षण के लिए सही तरीके से व्यवहार करती हैं। यदि आपके पास ये कक्षाएं उपलब्ध हैं और वे कोई अतिरिक्त निर्भरता नहीं पेश करते हैं, तो क्या यह नकली की बजाय वास्तविक चीज़ का उपयोग करना बेहतर नहीं है?मोक्स या असली कक्षाएं?
मैं कहता हूं कि जब भी आप कर सकते हैं असली कक्षाओं का उपयोग करें।
मैं जितना संभव हो सके "इकाई" परीक्षणों की सीमाओं का विस्तार करने में एक बड़ा आस्तिक हूं। इस बिंदु पर वे पारंपरिक अर्थ में वास्तव में यूनिट परीक्षण नहीं हैं, बल्कि आपके आवेदन के लिए केवल एक स्वचालित रिग्रेशन सूट हैं। मैं अभी भी टीडीडी का अभ्यास करता हूं और पहले अपने सभी परीक्षण लिखता हूं, लेकिन मेरे परीक्षण ज्यादातर लोगों की तुलना में थोड़ा बड़ा हैं और मेरे हरे रंग के लाल-हरे चक्र थोड़ा अधिक समय लेते हैं। लेकिन अब जब मैं थोड़ी देर के लिए ऐसा कर रहा हूं, मैं पूरी तरह से आश्वस्त हूं कि परंपरागत अर्थ में यूनिट परीक्षण वे सभी नहीं हैं जो वे क्रैक किए गए हैं।
मेरे अनुभव में छोटे यूनिट परीक्षणों का एक समूह लिखना भविष्य में रिफैक्टरिंग के लिए बाधा बनता है। अगर मेरे पास कक्षा ए है जो बी और आई यूनिट का उपयोग बी का मज़ाक उड़ाकर करता है, जब मैं ए से बी में कुछ कार्यक्षमता को स्थानांतरित करने का निर्णय लेता हूं या इसके विपरीत मेरे सभी परीक्षणों और मोक्स बदलना पड़ता है। अब अगर मेरे पास ऐसे परीक्षण हैं जो सत्यापित करते हैं कि सिस्टम के माध्यम से प्रवाह समाप्त होने का अंत अपेक्षित काम करता है तो मेरे परीक्षण वास्तव में उन स्थानों की पहचान करने में मेरी सहायता करते हैं जहां मेरे रिफैक्टरिंग सिस्टम के बाहरी व्यवहार में बदलाव कर सकते हैं।
नीचे की रेखा यह है कि मोजे किसी विशेष वर्ग के अनुबंध को संहिताबद्ध करते हैं और अक्सर वास्तव में कुछ कार्यान्वयन विवरण निर्दिष्ट करते हैं। यदि आप अपने परीक्षण सूट में बड़े पैमाने पर मैक्स का उपयोग करते हैं तो आपका कोड बेस बहुत अधिक जड़ता के साथ समाप्त होता है जो किसी भी भविष्य के रिफैक्टरिंग प्रयासों का विरोध करेगा।
जब तक आपके पास ऑब्जेक्ट पर पूर्ण नियंत्रण नहीं है तब तक "वास्तविक चीज़" का उपयोग करना ठीक है। उदाहरण के लिए यदि आपके पास कोई ऑब्जेक्ट है जिसमें केवल गुण और एक्सेसर्स हैं तो आप शायद ठीक हैं। यदि उस ऑब्जेक्ट में तर्क है जिसका आप उपयोग करना चाहते हैं, तो आप समस्याओं में भाग ले सकते हैं।
यदि कक्षा के लिए एक इकाई परीक्षण कक्षा बी के उदाहरण का उपयोग करता है और बी ब्रेक बी के साथ पेश किया गया परिवर्तन, तो वर्ग ए के परीक्षण भी टूटा हुआ है। यह वह जगह है जहां आप समस्याओं में भाग ले सकते हैं जहां एक नकली वस्तु के साथ आप हमेशा सही मूल्य वापस कर सकते हैं। "वास्तविक चीज़" का उपयोग करना, भरोसेमंद परीक्षणों और वास्तविक समस्या को छिपाने का तरीका हो सकता है।
मोक्स डाउनसाइड्स भी हो सकते हैं, मुझे लगता है कि कुछ मोजे और कुछ वास्तविक वस्तुओं के साथ संतुलन है जो आपको अपने लिए खोजना होगा।
वास्तविक चीज़ का उपयोग केवल तभी करें जब यह इकाई पहले परीक्षण किया गया हो। यदि यह उन निर्भरताओं को प्रस्तुत करता है जो इसे रोकते हैं (परिपत्र निर्भरता या यदि इसे पहले कुछ अन्य उपायों की आवश्यकता होती है) तो 'माक' वर्ग (आमतौर पर "स्टब" ऑब्जेक्ट के रूप में जाना जाता है) का उपयोग करें।
नकली कक्षाएं और स्टब ऑब्जेक्ट्स अलग-अलग चीजें नहीं हैं? – Oddmund
वहां सेमेटिक्स के बारे में बहस हो सकती है। मुझे अपने पेपर में फाउलर के भेद पसंद हैं: http://martinfowler.com/articles/mocksArentStubs.html यह बात यह है कि स्टब्स बस पूर्व-निर्धारित रिटर्न वैल्यू की सेवा करते हैं, और यह कि मैक्स यह सत्यापित करने के लिए अधिक हैं कि ऑब्जेक्ट्स अपेक्षित रूप से बातचीत कर रहे हैं । –
यदि आपकी 'वास्तविक चीजें' जावाबीन्स जैसी बस मूल्य वस्तुएं हैं तो यह ठीक है।
कुछ और जटिल के लिए मैं चिंता करता हूं क्योंकि नकली ढांचे से उत्पन्न मोक्स को सटीक उम्मीदों के बारे में बताया जा सकता है कि उनका उपयोग कैसे किया जाएगा। बुलाए गए तरीकों की संख्या, सटीक क्रम और प्रत्येक बार अपेक्षित पैरामीटर। आपकी असली वस्तुएं आपके लिए ऐसा नहीं कर सकती हैं ताकि आप अपने परीक्षणों में गहराई खोने का जोखिम उठा सकें।
यदि आप इंटरफेस के मामले में अपना कोड लिखते हैं, तो यूनिट परीक्षण एक खुशी बन जाता है क्योंकि आप किसी भी कक्षा के किसी भी वर्ग के नकली संस्करण को केवल उस कक्षा में इंजेक्ट कर सकते हैं, जिसका आप परीक्षण कर रहे हैं।
उदाहरण के लिए, यदि आपका डेटाबेस सर्वर किसी भी कारण से नीचे है, तो आप अभी भी नकली डेटा एक्सेस क्लास लिखकर इकाई परीक्षण कर सकते हैं जिसमें हैश मैप या कुछ में स्मृति में संग्रहीत कुछ पका हुआ डेटा शामिल है।
यदि आप अपने यूनिटयून्डरटेस्ट को चीज के साथ कैसे बातचीत करनी चाहिए, इस पर उम्मीदों की पुष्टि करने की परवाह नहीं है, और रीयलटिंग के साथ बातचीत के कोई अन्य दुष्प्रभाव नहीं हैं (या आप इन्हें दूर कर सकते हैं) तो यह मेरी राय में बिल्कुल ठीक है बस अपने यूनिटउंडटेस्ट को रीयलटिंग का उपयोग करने दें।
कि परीक्षण तब आपके कोड बेस को कवर करता है वह बोनस है।
मैं आम तौर पर यह बताने के लिए जब मैं एक RealThing के बजाय एक ThingMock का उपयोग करना चाहिए आसान है पाते हैं।
निर्भरता किसी निर्भरता के एक नकली संस्करण का उपयोग करती है यदि निर्भरता डेटाबेस या वेब सेवा जैसे बाहरी सिस्टम तक पहुंचती है।
यदि ऐसा नहीं है, तो यह दो वस्तुओं की जटिलता पर निर्भर करता है। वास्तविक निर्भरता के साथ परीक्षण के तहत वस्तु का परीक्षण अनिवार्य रूप से जटिलताओं के दो सेटों को गुणा करना है। निर्भरता का मज़ाक उड़ाते हुए मुझे ऑब्जेक्ट को परीक्षण के तहत अलग करने देता है। यदि कोई वस्तु उचित रूप से सरल है, तो संयुक्त जटिलता अभी भी काम करने योग्य है और मुझे नकली संस्करण की आवश्यकता नहीं है।
जैसा कि अन्य ने कहा है, निर्भरता पर एक इंटरफ़ेस परिभाषित करना और परीक्षण के तहत वस्तु में इंजेक्शन करना इसे मॉक करना आसान बनाता है।
व्यक्तिगत रूप से, मैं इस बारे में अनिश्चित हूं कि यह सख्त मोक्स का उपयोग करने के लिए इसके लायक है और निर्भरता पर प्रत्येक कॉल को मान्य करता है। मैं आमतौर पर करता हूं, लेकिन यह ज्यादातर आदत है।
आप भी इन से संबंधित प्रश्नों के लिए उपयोगी हो सकते:
मेरी नक़ल की बहुत आशंकित किया गया है वस्तुओं से मैं कई बार उनके द्वारा काटा गया है। जब आप अलग यूनिट परीक्षण चाहते हैं तो वे बहुत अच्छे हैं, लेकिन उनके पास कुछ समस्याएं हैं। मुख्य मुद्दा यह है कि अगर ऑर्डर क्लास को ऑर्डरइटम ऑब्जेक्ट्स के ए संग्रह को संग्रहित करने की आवश्यकता होती है और आप उन्हें नकल करते हैं, तो यह सत्यापित करना लगभग असंभव है कि मॉक किए गए ऑर्डरइटम क्लास का व्यवहार असली दुनिया के उदाहरण से मेल खाता है (उचित हस्ताक्षर वाले तरीकों को डुप्लिकेट करना आम तौर पर नहीं है पर्याप्त)। एक बार मैंने सिस्टम को एक बार विफल कर दिया है क्योंकि मॉक किए गए वर्ग वास्तविक लोगों से मेल नहीं खाते हैं और किनारे के मामलों को पकड़ने के लिए पर्याप्त एकीकरण परीक्षण नहीं थे।
मैं आमतौर पर गतिशील भाषाओं में प्रोग्राम करता हूं और मैं केवल विशिष्ट विधियों को ओवरराइड करना पसंद करता हूं जो समस्याग्रस्त हैं। दुर्भाग्यवश, स्थिर भाषाओं में कभी-कभी करना मुश्किल होता है। इस दृष्टिकोण का नकारात्मक पक्ष यह है कि आप इकाई परीक्षणों के बजाए एकीकरण परीक्षण का उपयोग कर रहे हैं और बग को कभी-कभी ट्रैक करना कठिन होता है। उलझन यह है कि आप उस कोड के मॉक किए गए संस्करण की बजाय लिखे गए वास्तविक कोड का उपयोग कर रहे हैं।
एक वास्तव में अच्छा कारण क्यों आप वास्तविक कक्षाओं के बजाय स्टब्स/मैक्स का उपयोग करना चाहते हैं। अर्थात। परीक्षण के तहत अपनी यूनिट टेस्ट (शुद्ध इकाई परीक्षण) कक्षा बनाने के लिए सब कुछ से अलग करें। यह संपत्ति बेहद उपयोगी है और अलग-अलग परीक्षणों को रखने के लिए लाभ भरपूर हैं:
अब आप अपने परीक्षण में वास्तविक वर्ग उपयोग करना चाहते हैं, यह ठीक है, लेकिन फिर यह नहीं एक इकाई परीक्षण है। आप इसके बजाय एकीकरण परीक्षण कर रहे हैं, जो के उद्देश्य के लिए उपयोगी आवश्यकताओं और समग्र सैनिटी चेक के प्रयोजन के लिए उपयोगी है। एकीकरण परीक्षण अक्सर यूनिट परीक्षण के रूप में नहीं चलाए जाते हैं, व्यावहारिक रूप से यह अधिकतर पसंदीदा कोड भंडार करने से पहले किया जाता है, लेकिन यह भी उतना ही महत्वपूर्ण है।
मजाक उड़ाता है और स्टब्स इकाई परीक्षण के लिए कर रहे हैं:
केवल एक चीज आप मन में है की जरूरत है निम्नलिखित है।
वास्तविक कक्षा एकीकरण/सिस्टम परीक्षण के लिए हैं।
निकाला जाता है और मेरा एक जवाब से बढ़ाया कैसे यहाँ मैं इकाई परीक्षण वस्तुओं इनहेरिट करना ">:
तुम हमेशा असली वस्तुओं जहां संभव हो उपयोग करना चाहिए
आप केवल नकली उपयोग करना चाहिए। ऑब्जेक्ट्स यदि असली ऑब्जेक्ट्स ऐसा कुछ करते हैं जिसे आप सेट अप नहीं करना चाहते हैं (जैसे सॉकेट, सीरियल पोर्ट्स, उपयोगकर्ता इनपुट प्राप्त करें, भारी डेटा पुनर्प्राप्त करें आदि)। अनिवार्य रूप से, नकली ऑब्जेक्ट्स तब होती हैं जब वास्तविक उपयोग करके परीक्षण को कार्यान्वित करने और बनाए रखने का अनुमान ऑब्जेक्ट एक मॉक ऑब्जेक्ट का उपयोग करके परीक्षण को कार्यान्वित करने और बनाए रखने के लिए उससे अधिक है।
मैं "आश्रित परीक्षण विफलता" तर्क में खरीद नहीं करता हूं। यदि कोई परीक्षण विफल रहता है क्योंकि एक निर्भर श्रेणी पर तोड़ दिया जाता है, तो परीक्षण ने वास्तव में किया था कि इसे क्या करना चाहिए था। यह एक गंध नहीं है! यदि एक निर्भर इंटरफ़ेस बदलता है, तो मैं जानना चाहता हूं!
अत्यधिक मजाक परीक्षण वातावरण बहुत उच्च रखरखाव हैं, खासकर एक परियोजना में जब इंटरफेस प्रवाह में हैं। Ive हमेशा एकीकरण परीक्षण ASAP शुरू करने के लिए बेहतर पाया।
यह अपने कोडिंग शैली, क्या आप कर रहे हैं, अपने अनुभव और अन्य बातों पर निर्भर करता है।
यह सब देखते हुए, से दोनों का उपयोग करके आपको कुछ भी नहीं रोक रहा है।
मुझे पता है कि मैं इकाई परीक्षण शब्द का उपयोग अक्सर करता हूं। मैं जो कुछ करता हूं उसे बेहतर एकीकरण परीक्षण कहा जा सकता है, लेकिन पर अभी भी बेहतर है, इसे परीक्षण के रूप में सोचें।
तो मैं उन सभी परीक्षण तकनीकों का उपयोग करने का सुझाव देता हूं जहां वे फिट होते हैं। परीक्षण का कुल उद्देश्य, थोड़ा समय लेना और व्यक्तिगत रूप से ठोस महसूस करना है कि यह सही है।
यह कहकर कि, आप कैसे प्रोग्राम करते हैं, इस पर निर्भर करते हुए, आप तकनीक (जैसे इंटरफेस) का उपयोग करने पर विचार करना चाहेंगे जो थोड़ा अधिक घुसपैठ कर रहा है। लेकिन इंटरफ़ेस और इंजेक्शन का उपयोग न करें जहां यह गलत है। इसके अलावा यदि नकली काफी जटिल होने की आवश्यकता है तो इसका उपयोग करने के लिए शायद कम कारण है। (आप यहां दिए गए उत्तरों में बहुत अच्छे मार्गदर्शन देख सकते हैं, जो कि फिट बैठता है।)
कोई अन्य तरीका रखें: कोई उत्तर हमेशा काम नहीं करता है। अपने बारे में अपने दिमाग रखें, देखें कि क्या काम करता है और क्यों नहीं।
मुझे इस तरह के दृष्टिकोण भी पसंद हैं, लेकिन 1. यह यूनिट परीक्षण नहीं है, लेकिन इंटेग्रेशन परीक्षण की तरह लगता है; 2. मुझे पसंद है, लेकिन मैं समझता हूं कि यह एक अच्छा दृष्टिकोण नहीं है। – Budda
"मुझे पसंद है, लेकिन मैं समझता हूं कि यह एक अच्छा दृष्टिकोण नहीं है।" किसके अनुसार? कुछ हद तक यह आपके लक्ष्यों पर निर्भर करता है। यदि आप एक छोटे से तरीके को लिखने की कोशिश कर रहे हैं जो एक विशेष विधि को अलग करते हैं ताकि आप एक इकाई को लागू करने के लिए अपने सिर को सबसे अच्छे तरीके से लपेट सकें, तो मैक्स सहायक होते हैं, लेकिन यदि आप एक रिग्रेशन सूट बनाने की कोशिश कर रहे हैं जो कोडिफाइड करेगा आपके सिस्टम का व्यवहार और अनपेक्षित रूप से बदलते समय आपको सतर्क करता है, यह मेरा अनुभव रहा है कि व्यापक नकली उपयोग निश्चित रूप से सबसे अच्छा तरीका नहीं है। –
हां "परंपरागत अर्थ में यूनिट परीक्षण वे सभी नहीं हैं जो वे" – Kemoda