हमें ढांचे के ढांचे की आवश्यकता क्यों है?

Question

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

Answer 1

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

यहाँ आप एक उदाहरण है:

var extension = MockRepository 
    .GenerateMock<IContextExtension<StandardContext>>(); 
    var ctx = new StandardContext(); 
    ctx.AddExtension(extension); 
    extension.AssertWasCalled(
    e=>e.Attach(null), 
    o=>o.Constraints(Is.Equal(ctx))); 

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

Answer 2

एक मॉकिंग लाइब्रेरी का उपयोग करने का एकमात्र कारण यह है कि यह मजाक करना आसान बनाता है।

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

Think लेकिन क्यों? यदि कोड पहले से मौजूद है और कॉल करना आसान है ... इसका उपयोग क्यों नहीं करें?

Answer 3

आपको अपनी ओर से नकली वस्तुओं को बनाने और निर्भरता इंजेक्शन चौखटे का उपयोग कर परीक्षण ... लेकिन दे ठट्ठे का ढांचा अपने नकली वस्तुओं उत्पन्न के लिए आप समय की बचत होती दौरान उन्हें इस्तेमाल कर सकते हैं।

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

Answer 4

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

Answer 5

एक मजाक ढांचे का उपयोग करना वास्तव में एक नकली वस्तु बनाने हर वस्तु के लिए आपका उपहास करना चाहते हैं की तुलना में mocks प्रदान करने के लिए एक और अधिक हल्के और सरल समाधान हो सकता है।

उदाहरण के लिए, मॉकिंग ढांचे विशेष रूप से काम करने के लिए उपयोगी होते हैं जैसे कि एक कॉल किया गया था (या यहां तक ​​कि कितनी बार कॉल किया गया था)। इस तरह के व्यवहार की जांच करने के लिए अपनी खुद की नकली वस्तुओं को बनाना (जबकि मजाक कर व्यवहार स्वयं एक विषय है) कठिन है, और फिर भी एक बग पेश करने के लिए एक और जगह है।

कैसे शक्तिशाली एक मजाक ढांचे हो सकता है का एक उदाहरण के लिए बाहर Rhino Mocks चेक।

Answer 6

कभी-कभी तीसरे पक्ष के पुस्तकालयों के साथ काम करते समय, या .NET ढांचे के कुछ पहलुओं के साथ काम करते समय, कुछ परिस्थितियों के लिए परीक्षण लिखना बेहद मुश्किल है - उदाहरण के लिए, एक HttpContext, या Sharepoint ऑब्जेक्ट। उन लोगों के लिए नकली वस्तुएं बनाना बहुत बोझिल हो सकता है, इसलिए मजाक करने वाले ढांचे मूल बातें का ख्याल रखते हैं ताकि हम अपने समय को ध्यान में रख सकें जो हमारे अनुप्रयोगों को अद्वितीय बनाता है।

Answer 7

नकली वस्तुएं चलाने के क्रम में आपके कोड की किसी भी बड़ी/जटिल/बाहरी वस्तुओं की जगह लेती हैं।

वे कुछ कारणों के लिए फायदेमंद होते हैं:

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

• आप मॉक ऑब्जेक्ट्स से सटीक आउटपुट को नियंत्रित कर सकते हैं और इसलिए उन्हें अपने परीक्षणों में नियंत्रित डेटा स्रोत के रूप में उपयोग कर सकते हैं।

• आप से पहले नकली बना सकते हैं, आप अपने इंटरफ़ेस को परिशोधित करने के लिए वास्तविक ऑब्जेक्ट बनाते हैं। यह टेस्ट-संचालित विकास में उपयोगी है।

Answer 8

खैर मजाक चौखटे मेरे जीवन बहुत आसान है और कम थकाऊ तो ​​मैं वास्तव में कोड लिखने पर समय बिताने कर सकते हैं। उदाहरण Mockito के लिए ले लो (जावा दुनिया में)

//mock creation 
List mockedList = mock(List.class); 

//using mock object 
mockedList.add("one"); 
mockedList.clear(); 

//verification 
verify(mockedList).add("one"); 
verify(mockedList).clear(); 

//stubbing using built-in anyInt() argument matcher 
when(mockedList.get(anyInt())).thenReturn("element"); 

//stubbing using hamcrest (let's say isValid() returns your own hamcrest matcher): 
when(mockedList.contains(argThat(isValid()))).thenReturn("element"); 

//following prints "element" 
System.out.println(mockedList.get(999)); 

हालांकि इस एक काल्पनिक उदाहरण है अगर आप के साथ MyComplex.class तो एक मजाक ढांचा होने के मूल्य स्पष्ट हो जाता है List.class बदलें। आप अपना खुद का लिख ​​सकते हैं या बिना कर सकते हैं लेकिन आप उस मार्ग पर क्यों जाना चाहेंगे।

Answer 9

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

बस हाथ से अपने स्वयं के नकली लिखने (और डिबगिंग) की बजाय मुझे आवश्यक सभी नकली वस्तुओं को उत्पन्न करने के लिए एक ढांचे का उपयोग करने के लिए बहुत तेज था।

Answer 10

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

उदाहरण के लिए यदि मेरे पास कक्षा ए है जिसमें व्यवसाय नियम और तर्क है जो मैं परीक्षण करना चाहता हूं, लेकिन यह कक्षा ए डेटा-एक्सेस कक्षाओं, अन्य व्यावसायिक वर्गों, यहां तक ​​कि u/i कक्षाओं आदि पर निर्भर करता है, ये अन्य कक्षाओं को आपके वर्ग ए के भीतर तर्क का परीक्षण करने के लिए एक निश्चित तरीके से (या ढीले नकली व्यवहार के मामले में किसी भी तरह से प्रदर्शन करने के लिए मजाक नहीं किया जा सकता है, जो कि इन अन्य वर्गों को उत्पादन वातावरण में आकस्मिक रूप से व्यवहार कर सकता है।

एक गहरी उदाहरण के लिए, मान लें कि आपकी क्लास ए एक डेटा का उपयोग वर्ग जैसे

public bool IsOrderOnHold(int orderNumber) {} 

तो उस डेटा का उपयोग वर्ग के एक नकली सच हर बार या पर लौटने के लिए सेटअप किया जा सकता है पर एक विधि का आह्वान है कि हर बार झूठी वापसी करें, यह जांचने के लिए कि आपकी कक्षा ए ऐसी परिस्थितियों का जवाब कैसे देती है।

Answer 11

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

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

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

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

मैं फ्रेमवर्क से दूर रहने के लिए किसी भी व्यक्ति (विशेष रूप से एक नौसिखिया) की सिफारिश करता हूं और सीखता हूं कि उनके बिना कैसे प्राप्त किया जाए, और बाद में जब उन्हें लगता है कि उन्हें वास्तव में वे जो भी ढांचे का उपयोग कर सकते हैं, वे सबसे उपयुक्त हैं , लेकिन तब तक यह एक सूचित desicion होगा और वे खराब कोड बनाने के लिए ढांचे का दुरुपयोग करने की संभावना कम होगी।