यूनिट परीक्षण में एकाधिक assert खराब हैं? यहां तक ​​कि चेनिंग भी?

Question

क्या इस इकाई परीक्षण ?:

ActualModel = ActualResult.AssertViewRendered()  // check 1 
          .ForView("Index")   // check 2 
          .WithViewData<List<Page>>(); // check 3 

CollectionAssert.AreEqual(Expected, ActualModel);  // check 4 

इस परीक्षण के प्राथमिक लक्ष्यों में बहुत सी बातें की जाँच के साथ कुछ गलत (जाँच 2) सही दृश्य दिया जाता है सत्यापित करने के लिए कर रहे हैं और यह सही डेटा (जांच में शामिल है 4)।

क्या मुझे इसे कई परीक्षणों में विभाजित करके कुछ हासिल होगा? मैं सबकुछ सही करने के बारे में हूं, लेकिन अगर चीजों का व्यावहारिक मूल्य नहीं है तो मैं चीजों को विभाजित नहीं कर रहा हूं।

मैं यूनिट परीक्षण के लिए काफी नया हूं, इसलिए नम्र रहें।

Answer 1

जैसा कि अन्य ने बताया है, जानकारी खोने से बचने के लिए प्रत्येक परीक्षण में एक जोर से चिपकना सर्वोत्तम है - यदि पहला दावा विफल रहता है, तो आप नहीं जानते कि बाद वाले लोग भी असफल हो जाएंगे। आपको कम जानकारी के साथ समस्या को ठीक करना होगा - जो शायद (शायद होगा) कठिन हो सकता है।

रॉय ओशरोव के Art of Unit Testing का एक बहुत अच्छा संदर्भ है - यदि आप यूनिट परीक्षण के साथ सही शुरुआत करना चाहते हैं, तो आप यहां से शुरू करने से बहुत खराब कर सकते हैं।

Answer 2

Assertion Roulette से बचने के लिए प्रत्येक परीक्षण में केवल एक ही जोर से चिपकना सर्वोत्तम है।

यदि आपको समान परिसर के आधार पर कई स्थितियों का परीक्षण करने के लिए एक ही परिदृश्य स्थापित करने की आवश्यकता है, तो एक साझा सहायक विधि में सेटअप कोड निकालना बेहतर है, और फिर इस सहायक विधि को कॉल करने वाले कई परीक्षण लिखें।

यह सुनिश्चित करता है कि प्रत्येक परीक्षण केस केवल एक चीज का परीक्षण करता है।

हमेशा की तरह, इस नियम के अपवाद हैं, लेकिन जब से तुम इकाई परीक्षण के लिए नए हैं, मैं सुझाव है कि आप जब तक आप सीखा है इकाई परीक्षण नियम के अनुसार एक दावे से चिपके रहते हैं, जब यह विचलित करने के लिए ठीक है ।

Answer 3

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

Answer 4

भावी पाठकों के लिए नोट करना कि यह प्रश्न और इसके डुप्लिकेट Is it bad practice to have more than one assertion in a unit test? के विपरीत बहुमत हैं, इसलिए उन्हें दोनों पढ़ें और स्वयं के लिए निर्णय लें।

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

Answer 5

मैं (कम से कम खुद के लिए) इस सवाल का एक अलग तर्क पाया है:

कई की

उपयोग का दावा है ठीक है अगर वे एक ही बात का परीक्षण कर रहे हैं।

उदाहरण के लिए, यह करने के लिए ठीक है:

Assert.IsNotNull(value); 
Assert.AreEqual(0, value.Count); 

क्यों? - क्योंकि ये दो आवेषण परीक्षण के इरादे को छुपा नहीं रहे हैं। यदि पहला दावा विफल रहता है, तो इसका मतलब है कि दूसरा भी विफल हो जाएगा। और वास्तव में, अगर हम पहले जोर को हटा देते हैं, तो दूसरा दावा विफल रहता है (शून्य संदर्भ अपवाद के साथ - !!!) वैसे भी जब value शून्य है। यदि यह मामला नहीं था, तो हमें इन दोनों आवेषणों को एक साथ नहीं रखना चाहिए।

तो, यह गलत है:

Assert.IsNotNull(value1); 
Assert.IsNotNull(value2); 

मैं ऊपर उल्लेख किया है, अगर पहले ज़ोर विफल रहता है, वहां दूसरे ज़ोर के बारे में कोई स्पष्ट संकेत है - हम अभी भी पता है कि करने के लिए होता चाहेगा दूसरा एक (भले ही पहला वाला विफल हो)। इसलिए, इस कारण से, ये दो आवेषण दो अलग-अलग यूनिट परीक्षणों से संबंधित हैं।

निष्कर्ष: एक या अधिक, का दावा है जब ठीक से किया, वरीयता के मामले हो जाता है डाल - हम परीक्षण के परिणाम में जोर अपवाद देखना चाहते हैं, या हम कुछ अन्य अपवादों को देखने के लिए और साथ ही विशेष रूप से चाहते हैं कि क्या मामलों।

Answer 6

मुझे पता है कि यह एक पुराना सवाल है, लेकिन मैंने सोचा कि मैं अपना बिट जोड़ूंगा।

आम तौर पर मेरे पास प्रत्येक टेस्ट केस में जितना संभव हो उतना दावा होगा। कई अलग-अलग दावों को बचाने के लिए टेस्ट को अक्सर लिखा जा सकता है।

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

निम्नलिखित कोड को देखते हुए, कई अलग-अलग दावे हैं। जब वे असफल होते हैं तो आप एक समय में उन्हें एक बार ठीक कर सकते हैं जब तक कि दावे बंद नहीं हो जाते।

Assert.AreEqual("Mr Smith", GetSalutation("Mr", "J", "Smith")); 
Assert.AreEqual("Mr Smith", GetSalutation("Mr", "John", "Smith")); 
Assert.AreEqual("Sir/Madam", GetSalutation("", "John", "Smith")); 
Assert.AreEqual("Sir/Madam", GetSalutation("", "J", "Smith")); 

इसका एक विकल्प मुद्दों की गिनती रखना और अंत में इसे जोर देना है। http: // stackoverflow

int errorCount = 0; 
string result; 

result = GetSalutation("Mr", "J", "Smith"); 
if (result == "Mr Smith") 
    errorCount++; 

result = GetSalutation("Mr", "John", "Smith"); 
if (result == "Mr Smith") 
    errorCount++; 

Assert.AreEqual(0, errorCount); 

मैं शायद कुछ ट्रेस जोड़ते हैं वह एक वास्तविक दुनिया की स्थिति में अलग-अलग परीक्षण जो उत्पादन खिड़की