पॉको ऑब्जेक्ट्स के लिए परीक्षण कैसे बनाएं

Question

मैं मॉकिंग/परीक्षण करने के लिए नया हूं और जानना चाहता हूं कि परीक्षण के दौरान आपको किस स्तर पर जाना चाहिए। उदाहरण के लिए मेरे कोड में मेरे पास निम्न ऑब्जेक्ट है:

public class RuleViolation 
{ 
    public string ErrorMessage { get; private set; } 
    public string PropertyName { get; private set; } 

    public RuleViolation(string errorMessage) 
    { 
     ErrorMessage = errorMessage; 
    } 

    public RuleViolation(string errorMessage, string propertyName) 
    { 
     ErrorMessage = errorMessage; 
     PropertyName = propertyName; 
    } 
} 

यह अपेक्षाकृत सरल वस्तु है। तो मेरा सवाल है:

क्या इसे यूनिट परीक्षण की आवश्यकता है?

यदि यह करता है तो मैं परीक्षण करता हूं और कैसे?

धन्यवाद

Answer 1

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

public string ErrorMessage { get; private set; } 
public string PropertyName { get; private set; } 

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

class Program 
    { 
     static void Main(string[] args) 
     { 
      var property = typeof(Test).GetProperty("Accessor"); 

      var methods = property.GetAccessors(); 
     } 
    } 



    public class Test 
    { 
     public string Accessor 
     { 

      get; 
      private set; 
     }  

    } 

property.GetAccessors();

आप देख सकते हैं के साथ

:

यहाँ कैसे आप एक संपत्ति में accessors मिल सकता है। यदि यह है, तो सेटर सार्वजनिक है। (संपत्तियां IsPrivate और IsPublic भी हैं जो आप अन्य एक्सेसर्स को सत्यापित करने के लिए भी उपयोग कर सकते हैं)।

Answer 2

यह किसी भी तर्क शामिल नहीं है => परीक्षण करने के लिए कुछ भी नहीं

Answer 3

यहां तक ​​कि यदि सरल है, तो आपके रचनाकारों में तर्क है। मुझे लगता है कि परीक्षण होगा:

RuleViolation ruleViolation = new RuleViolation("This is the error message"); 
Assert.AreEqual("This is the error message", ruleViolation.ErrorMessage); 
Assert.IsEmpty(ruleViolation.PropertyName); 

RuleViolation ruleViolation = new RuleViolation("This is the error message", "ThisIsMyProperty"); 
Assert.AreEqual("This is the error message", ruleViolation.ErrorMessage); 
Assert.AreEqual("ThisIsMyProperty", ruleViolation.PropertyName); 

Answer 4

आप सकता है इकाई परीक्षण इस वस्तु है, लेकिन यह के रूप में यह आवश्यकता नहीं करने के लिए इतना आसान है। परीक्षण की तरह कुछ (NUnit उदाहरण)

[Test] 
public void TestRuleViolationConstructorWithErrorMessageParameterSetsErrorMessageProperty() { 
    // Arrange 
    var errorMessage = "An error message"; 

    // Act 
    var ruleViolation = new RuleViolation(errorMessage); 

    // Assert 
    Assert.AreEqual(errorMessage, ruleViolation.ErrorMessage); 
} 

वहाँ इस तरह के परीक्षण लेखन के लिए कम महत्व है हो सकता है, हालांकि, आप परीक्षण कर रहे हैं के रूप में जो .NET ढांचे के गुणों को सही ढंग से काम करते हैं। आम तौर पर आप इस अधिकार को प्राप्त करने के लिए माइक्रोसॉफ्ट पर भरोसा कर सकते हैं :-)

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

[Test] 
public void TestCalculateReturnsBasicRateTaxForMiddleIncome() { 
    // Arrange 
    // TaxPolicy is a dependency that we need to manipulate. 
    var policy = new Mock<TaxPolicy>(); 
    bar.Setup(x => x.BasicRate.Returns(0.22d)); 

    var taxCalculator = new TaxCalculator(); 

    // Act 
    // Calculate takes a TaxPolicy and an annual income. 
    var result = taxCalculator.Calculate(policy.Object, 25000); 

    // Assert 
    // Basic Rate tax is 22%, which is 5500 of 25000. 
    Assert.AreEqual(5500, result); 
} 

TaxPolicy सत्यापित करें कि यह सही ढंग से कार्य अपने आप ही स्थिरता में परीक्षण इकाई होगा: निर्भरता के साथ एक बुनियादी वर्ग के लिए परीक्षण कुछ इस तरह दिखेगा। यहां, हम परीक्षण करना चाहते हैं कि TaxCalculator सही तरीके से काम करता है, और इसलिए हम अपने परीक्षणों को सरल बनाने के लिए TaxPolicy ऑब्जेक्ट का नकल करते हैं; ऐसा करने में, हम TaxPolicy की बिट्स के व्यवहार को निर्दिष्ट कर सकते हैं जिसमें हम रुचि रखते हैं। इसके बिना, हमें हाथ से लुढ़का हुआ मॉक्स/स्टब्स/नकली बनाने की आवश्यकता होगी, या TaxPolicy के वास्तविक उदाहरणों को पारित करने की आवश्यकता होगी।

हालांकि, इसके मुकाबले मोक के लिए और अधिक है; यह देखने के लिए quick-start tutorial देखें कि यह क्या कर सकता है।

Answer 5

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

ऐसा करके, आप केवल वही मान्य नहीं करते हैं जो आपने इरादे के अनुसार काम किया है, लेकिन आपके पास सामान्य परिदृश्यों के माध्यम से सोचने का अवसर है (क्या होता है यदि सीटीओआर पैराम शून्य या खाली हैं या अंत में सफेद जगह है? क्यों? एक अपरिवर्तनीय वर्ग में PropertyName वैकल्पिक है?)।

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

यह आपके कोड को इंजीनियर करने का सही तरीका है।

HTH,
Berryl