कैसे यूनिट परीक्षण DRY रखने और Asserts को कम करने के लिए

Question 1

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

परीक्षणों का एक गुच्छा लिखने के बाद मैंने महसूस किया कि मैंने अपने आप को व्यवस्था चरण में दोहराया है:

var mock = new Mock<ISomeWebservices>();
var sut = new MyWebServiceClass(mock.Object);
mock.Setup(foo=>foo.SomeRequest(someData)).Returns(@"{""user"": ""12345"",""somedata"": ""60"",""someotherdata"":""2015-09-01T12:00:00.200Z""}");
sut.SomeRequest(someData,s=> response = s);

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

दूसरी समस्या जोर चरण है। चूँकि मुझे हमेशा अनुरोध से एक त्रुटि वस्तु मिलती है, मैं केवल त्रुटि वस्तु का दावा करता हूँ अगर मैं समय सीमा और त्रुटि हूँ।

    Assert.That(response.Error.Type,Is.EqualTo(ErrorInfo.ErrorType.IllegalToken));
    Assert.That(response.Error.Message, Is.Not.Null);
    Assert.That(response.Error.AdvisedAction, Is.Not.Null);
    Assert.That(response.Error.RawData, Is.Not.Null);

इसलिए यदि कोई त्रुटि है, तो त्रुटि ऑब्जेक्ट के कुछ गुण हैं जिन्हें हमेशा भरा जाना चाहिए और कुछ हो सकता है। (f.e. यदि त्रुटि को एक अपवाद द्वारा ट्रिगर किया गया था, तो अपवाद गुण शून्य नहीं होना चाहिए) जहाँ तक मुझे समझ में आया, एक इकाई परीक्षण में कई Asserts का होना एक बुरा अभ्यास है, इसलिए यदि संभव हो तो मैं इससे बचना चाहूंगा।

[संपादित करें] टिप्पणी के अनुसार, कई एसेर्ट्स के साथ-साथ मेरे द्वारा बताए गए व्यवस्था भागों को दोहराते हुए, यह उतना बुरा नहीं है। तो मैं उस के लिए Autofixture का उपयोग नहीं करूंगा।

c# tdd nunit moq autofixture

4

zlZimon 18 नवम्बर 2015, 21:15

Answer

आप सबसे निश्चित रूप से AutoFixture का उपयोग अपने व्यवस्था चरण में बॉयलरप्लेट कोड की मात्रा को कम करने के लिए कर सकते हैं। यह इस तरह दिख सकता है:

[Theory, AutoMoqData]
public void Test(
    [Frozen]Mock<ISomeWebservices> mock,
    MyWebServiceClass sut,
    object someData,
    object response)
{
    mock.Setup(foo => foo.SomeRequest(someData)).Returns(@"{""user"": ""12345"",""somedata"": ""60"",""someotherdata"":""2015-09-01T12:00:00.200Z""}");
    sut.SomeRequest(someData, s => response = s);
    // Assertions go here...
}

यहाँ, मुझे someData और response के प्रकार का अनुमान लगाना था, लेकिन यदि वे object से भिन्न हैं, तो आप उन्हें इसके बजाय उसी प्रकार का घोषित करते हैं।

उपरोक्त उदाहरण में, [AutoMoqData] विशेषता को इस तरह परिभाषित किया गया है:

public class AutoMoqDataAttribute : AutoDataAttribute
{
    public AutoMoqDataAttribute() :
        base(new Fixture().Customize(new AutoMoqCustomization()))
    {
    }
}

अन्य सभी प्रकार और AutoFixture सुविधाएँ AutoFixture.Xunit.net और AutoFixture.AutoMoq NuGet पैकेज।

जब यह कई कथनों पर आता है, तो मैं यहां अन्य टिप्पणीकारों से सहमत हूं कि यह उतना बुरा नहीं लगता है, लेकिन GOOS <की भावना में / a>, आपको अपने परीक्षण सुनना चाहिए । इस विशेष मामले में, परीक्षण यह कहता है: response के लिए समानता की तुलना यह महत्वपूर्ण है। यदि यह मामला है, तो आप {{X2} पर Equals ओवरराइड करने पर विचार कर सकते हैं। } और इसे संदर्भ समानता के बजाय संरचनात्मक समानता दें।

4

Mark Seemann 19 नवम्बर 2015, 19:15

Answer

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

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

परीक्षण के प्रति एकाधिक दावे ठीक हैं (शायद आवश्यक हैं), बस सुनिश्चित करें कि दावे प्रासंगिक हैं और परीक्षण एकल अवधारणा से चिपक जाता है, जिससे त्रुटियों को जल्दी से पहचानने में मदद मिलती है।

3

MikeJ 19 नवम्बर 2015, 14:36

Question 2