जुनीट परीक्षणों में वस्तुओं का मज़ाक उड़ाते हुए - सर्वोत्तम अभ्यास?

Question

क्या आपको लगता है कि जुनीट टेस्ट में मॉकिंग ऑब्जेक्ट्स बेस्ट अभ्यास है? मुझे बड़ा फायदा नहीं दिख रहा है। निश्चित रूप से यदि आपके पास एक डेटाबेस है जिसे आपके परीक्षण में नहीं माना जाना चाहिए, तो यह समझ में आता है, लेकिन उस घटक के अन्य कार्यान्वयन को क्यों इंजेक्शन नहीं दिया जाता है (यदि वसंत का उपयोग किया जाता है)। परीक्षणों के लिए एक वस्तु कारखाना यह बहुत आसान बना देगा। मेरे पास ज्यादा अनुभव नहीं है (हम मॉकिटो का उपयोग कर रहे हैं), लेकिन मैंने पहले ही देखा है, कि एप्लिकेशन कोड संशोधित हो जाता है ताकि कुछ गुण मजाक कर सकें! टेस्ट मामलों को कभी भी मेरे विरोध में उत्पादक कोड में ऐसे परिवर्तनों को प्रभावित नहीं करना चाहिए।

तो आप इस विषय के बारे में क्या सोचते हैं? आप किस मामले में अपनी वस्तु का मज़ाक उड़ा रहे हैं या आप क्यों नहीं करते?

Answer 1

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

एक वस्तु कारखाना शायद stubbed तरीकों के साथ वस्तुओं बनाना होगा, और mocking चौखटे अनिवार्य रूप से परीक्षण में इस्तेमाल के लिए सामान्य वस्तु कारखाने हैं। लेकिन मोजे स्टब्स से बहुत अधिक प्रदान करते हैं - एक अंतर जो मार्टिन फाउलर यहां विस्तार से जाता है: http://martinfowler.com/articles/mocksArentStubs.html।

यदि आपको कठिन लग रहा है, और आप यह भी पाते हैं कि आप इसमें बहुत कुछ कर रहे हैं, तो यह टीडीडी का एक उत्कृष्ट उदाहरण है जो आपको बता रहा है कि आपका डिज़ाइन बेहतर हो सकता है।

Answer 2

मैं पहले से ही देखा है, कि आवेदन कोड को संशोधित किया जाता है ताकि कुछ गुण mockable हो जाता है! टेस्ट केस को मेरे विपक्ष में उत्पादक कोड में ऐसे परिवर्तनों को कभी भी प्रभावित नहीं करना चाहिए।

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

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

Answer 3

• कक्षाएं कैलिब्रेट इंटरफेस को परिभाषित करता है
• नीचे डिजाइन करने के लिए शीर्ष की अनुमति देता है
• अलगाव (इकाई परीक्षण)
• कभी कभी ही देखने के लिए जिस तरह से कक्षाएं
के बीच संबंधों स्पष्ट किया ऑब्जेक्ट करता है जो आप चाहते हैं ( Mocks and Tell Don’t Ask)
• बेहतर संरचित परीक्षणों को प्रोत्साहित किया गया। उदाहरण के लिए, jukito स्वत: इंजेक्शन मैक्स आपको उन चीजों पर ध्यान केंद्रित करने में सक्षम बनाता है जिन्हें आप परीक्षण करना चाहते हैं।
• कैप्सूलीकरण संरक्षण

• कम कर देता है निर्भरता

• मूल्य वस्तु

आवश्यकता से

मजाक चौखटे grow-out नहीं मज़ाक उड़ाया जाना चाहिए देता है। जैसा कि मैथ्यू गिलियर्ड ने कहा था, अगर मॉकरी पर जा रहा है, तो यह संकेत है कि डिजाइन में सुधार या परीक्षण फोकस की कमी हो सकती है। टेस्ट कोड में कई समस्याओं का खुलासा करता है।

लेकिन क्यों नहीं उस घटक के अन्य कार्यान्वयन को इंजेक्शन दिया जाता है (यदि वसंत का उपयोग किया जाता है)।

आपको कार्यान्वयन लिखना है। मॉकिंग फ्रेमवर्क का उपयोग करना यह आपके लिए किया जाता है।

मैंने पहले ही देखा है कि एप्लिकेशन कोड संशोधित हो जाता है ताकि कुछ गुण मजाक कर सकें! टेस्ट मामलों को कभी भी मेरी राय में उत्पादक कोड में ऐसे परिवर्तनों का प्रयास नहीं करना चाहिए। mockable परीक्षण योग्य मतलब है

तो यह दूसरी तरह के आसपास है। उदाहरण के लिए, टीडीडी परीक्षण में उत्पादन कोड परिभाषित करता है।

Answer 4

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

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

भ्रम कुछ मनमाने ढंग से इस तरह के final या static तरीकों नकली करने में असमर्थता, या परीक्षण इकाई सीधे नकली वस्तुओं परीक्षण कोड में बनाया का उपयोग की आवश्यकता के रूप में कुछ मजाक उपकरण में पाया सीमाओं, से उत्पन्न होती है। अन्य मॉकिंग टूल में इन सीमाएं नहीं हैं, और इसलिए यह आवश्यक नहीं है कि "एप्लिकेशन कोड संशोधित हो जाए ताकि कुछ गुण मज़ेदार हो जाएं"। आधुनिक प्रोग्रामिंग भाषाओं/प्लेटफार्मों (जावा, सी #, पायथन, रूबी, आदि) के साथ सब कुछ मजाकिया है; यह सिर्फ एक मजाकिया एपीआई में इस शक्ति को उजागर करने का मामला है, और यह उन भाषाओं में से प्रत्येक के लिए पहले से ही किया जा चुका है (पूर्ण प्रकटीकरण के हित में, मैं एक ऐसा टूल विकसित करता हूं)।