यूनिट परीक्षण शून्य विधियों/मॉकिंग ऑब्जेक्ट टेल-टेल संकेत

Question

जब इकाई कोडबेस का परीक्षण करती है, तो मुझे मॉक ऑब्जेक्ट्स का उपयोग करने के लिए बताए जाने वाले बताने वाले संकेत क्या हैं?

क्या यह कोडबेस में अन्य ऑब्जेक्ट्स के लिए बहुत सी कॉल देखने के समान आसान होगा?

इसके अलावा, मैं यूनिट परीक्षण विधियों को कैसे मानूं जो मान वापस नहीं करते? तो अगर मैं एक विधि शून्य लौट रहा हूं लेकिन फ़ाइल में प्रिंट करता हूं, तो क्या मैं सिर्फ फाइल की सामग्री जांचता हूं?

मॉकिंग बाहरी निर्भरताओं के लिए है, तो यह सचमुच सबकुछ है, नहीं? फाइल सिस्टम, डीबी, नेटवर्क, आदि ...

Answer 1

यदि कुछ भी हो, तो शायद मैं मोज़े का उपयोग कर सकता हूं।

जब भी कोई वर्ग दूसरे को कॉल करता है, आम तौर पर मैं उस कॉल को मजाक करता हूं, और मैं सत्यापित करता हूं कि कॉल सही पैरामीटर के साथ किया गया था। अन्यथा, मेरे पास एक यूनिट टेस्ट होगा जो मैक आउट ऑब्जेक्ट का कंक्रीट कोड सही तरीके से व्यवहार करता है।

उदाहरण:

[Test] 
public void FooMoo_callsBarBaz_whenXisGreaterThan5() 
{ 
    int TEST_DATA = 6; 
    var bar = new Mock<Bar>(); 
    bar.Setup(x => x.Baz(It.Is<int>(i == TEST_DATA))) 
     .Verifiable(); 

    var foo = new Foo(bar.Object); 

    foo.moo(TEST_DATA); 

    bar.Verify(); 
} 

... 
[Test] 
public void BarBaz_doesSomething_whenCalled() 
{ 
    // another test 
} 

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

मुझे छोटे संक्षिप्त परीक्षण पसंद हैं। लिखने के लिए आसान, बनाए रखने में आसान, परीक्षण के इरादे को समझना आसान है।

Answer 2

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

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

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

यदि संभव हो तो आपको हमेशा एक मूल्य वापस करने का प्रयास करना चाहिए। कभी-कभी आप उन समस्याओं में भाग लेते हैं जहां आप पहले से कुछ लौट रहे हैं, लेकिन सी और सी ++ में आपके पास आउटपुट पैरामीटर हो सकते हैं और फिर त्रुटि जांच के लिए रिटर्न वैल्यू का उपयोग कर सकते हैं।

Answer 3

मोक्स/स्टब्स/नकली/परीक्षण युगल/आदि। यूनिट परीक्षणों में ठीक है, और अलगाव में परीक्षण के तहत कक्षा/प्रणाली का परीक्षण करने की अनुमति देता है। एकीकरण परीक्षण किसी भी झुंड का उपयोग नहीं कर सकता है; वे वास्तव में डेटाबेस या अन्य बाहरी निर्भरता मारा।

जब आप करना चाहते हैं तो आप एक नकली या स्टब का उपयोग करते हैं। आम तौर पर ऐसा इसलिए होता है क्योंकि जिस वर्ग को आप परीक्षण करने का प्रयास कर रहे हैं वह एक इंटरफ़ेस पर निर्भरता है। टीडीडी के लिए आप इंटरफेस, कार्यान्वयन नहीं, और निर्भरता इंजेक्शन (आमतौर पर बोलने) का उपयोग करना चाहते हैं।

एक बहुत ही सरल मामला:

public class ClassToTest 
{ 
    public ClassToTest(IDependency dependency) 
    { 
     _dependency = dependency; 
    } 

    public bool MethodToTest() 
    { 
     return _dependency.DoSomething(); 
    } 
} 

IDependency एक अंतरफलक, संभवतः महंगा कॉल (डेटाबेस का उपयोग, वेब सेवा कॉल, आदि) के साथ एक है। एक परीक्षा पद्धति के समान कोड शामिल हो सकता है:

// Arrange 

var mock = new Mock<IDependency>(); 

mock.Setup(x => x.DoSomething()).Returns(true); 

var systemUnderTest = new ClassToTest(mock.Object); 

// Act 

bool result = systemUnderTest.MethodToTest(); 

// Assert 

Assert.That(result, Is.True); 

ध्यान दें कि मैं राज्य परीक्षण कर रहा हूँ (के रूप में @Finglas सुझाव दिया), और मैं केवल परीक्षण के अंतर्गत व्यवस्था के खिलाफ जोर देते हुए कर रहा हूँ (कक्षा मैं के कहने एम परीक्षण)। मैं संपत्ति मूल्य (राज्य) या विधि के वापसी मूल्य की जांच कर सकता हूं, क्योंकि यह मामला दिखाता है।

मैं The Art of Unit Testing पढ़ने की अनुशंसा करता हूं, खासकर यदि आप .NET का उपयोग कर रहे हैं।