एक उदाहरण के रूप में NUnit का उपयोग कर एक इकाई परीक्षण में रुकावट के बिना कई दावे

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

तो, मान लें कि हमारे पास एक आकार वर्ग है, जो अन्य चीजों के अलावा, कंस्ट्रक्टर पैरामीटर को इंच में लेता है और इसमें पूरे पैर की संख्या और शेष इंच तक पहुंचने के लिए एक्सेसर्स होते हैं, यानी इनपुट में 16 पास करने पर, हमें 1 फीट मिलता है और 4 इंच (एक पैर में 12 इंच)।

public class Size { public int Feet { get; private set; } public int RemainderInches { get; private set; } public Size(int totalInches) { //   } //... } 

पेड़ पर डिजाइनर के परीक्षणों का प्रसार नहीं करने के लिए और एक ही समय में उपयुक्त कवरेज प्रदान करने के लिए, मैं कुछ इस तरह लिखना चाहता हूं:

 [Test] public void ConstructorSuccess() { var zeroSize = new Size(0); var inchesOnlySize = new Size(2); var mixedSize = new Size(15); var feetOnlySize = new Size(36); Assert.That(zeroSize.Feet == 0 && zeroSize.RemainderInches == 0, "Zero size"); Assert.That(inchesOnlySize.Feet == 0 && inchesOnlySize.RemainderInches == 2, "Inches-only size"); Assert.That(mixedSize.Feet == 1 && mixedSize.RemainderInches == 3, "Inches and feet size"); Assert.That(feetOnlySize.Feet == 3 && feetOnlySize.RemainderInches == 0, "Feet-only size"); } 

डिस्क्लेमर: केवल सत्य की जाँच करने के बजाय, आप समानता के लिए दो चेक का उपयोग कर सकते हैं (और यहां तक ​​कि अच्छा भी होगा), लेकिन इस संक्षिप्त उदाहरण में यह महत्वपूर्ण नहीं है, और कोड जटिल होगा।

यह स्पष्ट है कि यदि हम विधि द्वारा प्रत्येक ऐसे अभिकथन को आवंटित करते हैं, तो हमारा परीक्षण वर्ग जल्दी से बड़ी संख्या में तरीकों से विकसित होगा और वास्तव में, हमारे पास सैकड़ों परीक्षण होंगे, लेकिन कोई अधिक समझ नहीं है। हालांकि, दिखाए गए दृष्टिकोण में, जैसा कि पहले ही उल्लेख किया गया है, जब एक जोर पड़ता है, तो हम दूसरों से डेटा नहीं देखेंगे, क्योंकि विधि निष्पादन बंद हो जाएगा।

हम इस असुविधा को खत्म करने के लिए आगे बढ़ते हैं।

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

कुछ विचारों के बाद, इन उद्देश्यों के लिए एक बैटरी वर्ग प्रस्तावित किया गया था, जिसका उपयोग परीक्षण विधि के अंदर उपरोक्त उदाहरण से होता है:

 var assertsAccumulator = new AssertsAccumulator(); assertsAccumulator.Accumulate( () => Assert.That(zeroSize.Feet == 0 && zeroSize.RemainderInches == 0, "Zero size")); assertsAccumulator.Accumulate( () => Assert.That(inchesOnlySize.Feet == 0 && inchesOnlySize.RemainderInches == 2, "Inches-only size")); assertsAccumulator.Accumulate( () => Assert.That(mixedSize.Feet == 1 && mixedSize.RemainderInches == 3, "Inches and feet size")); assertsAccumulator.Accumulate( () => Assert.That(feetOnlySize.Feet == 3 && feetOnlySize.RemainderInches == 0, "Feet-only size")); assertsAccumulator.Release(); 

एक अन्य उपयोग मामला (मुझे उम्मीद है कि कोड खुद के लिए बोलता है और टिप्पणी के बिना समझ में आता है):

 Result<User> signInResult = authService.SignIn(TestUsername, TestPassword); var assertsAccumulator = new AssertsAccumulator(); assertsAccumulator.Accumulate(() => Assert.That(signInResult.IsSuccess)); assertsAccumulator.Accumulate(() => Assert.That(signInResult.Value, Is.Not.Null)); assertsAccumulator.Accumulate(() => Assert.That(signInResult.Value.Username, Is.EqualTo(TestUsername))); assertsAccumulator.Accumulate(() => Assert.That(signInResult.Value.Password, Is.EqualTo(HashedTestPassword))); assertsAccumulator.Release(); 

दो त्रुटियों के निष्कर्ष के साथ इस उदाहरण को निष्पादित करने का परिणाम पोस्ट की शुरुआत में एक मोहक स्क्रीन पर दिखाया गया है।

AssertsAccumulator कार्यान्वयन इस तरह दिखता है:

 public class AssertsAccumulator { private StringBuilder Errors { get; set; } private bool AssertsPassed { get; set; } private String AccumulatedErrorMessage { get { return Errors.ToString(); } } public AssertsAccumulator() { Errors = new StringBuilder(); AssertsPassed = true; } private void RegisterError(string exceptionMessage) { AssertsPassed = false; Errors.AppendLine(exceptionMessage); } public void Accumulate(Action assert) { try { assert.Invoke(); } catch (Exception exception) { RegisterError(exception.Message); } } public void Release() { if (!AssertsPassed) { throw new AssertionException(AccumulatedErrorMessage); } } } 

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

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

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