38

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

[TestMethod] 
[ExpectedException(typeof(CriticalException))] 
public void GetOrganisation_MultipleOrganisations_ThrowsException() 

तुम भी संदेश इस तरह ExpectedException के भीतर निहित के लिए जाँच कर सकते हैं:: आप इस तरह एक अपवाद में पारित कर सकते हैं

[TestMethod] 
[ExpectedException(typeof(CriticalException), "An error occured")] 
public void GetOrganisation_MultipleOrganisations_ThrowsException() 

लेकिन मैं संसाधन फ़ाइल का प्रयोग करेंगे जब I18N अनुप्रयोगों का परीक्षण पाने के लिए कि त्रुटि संदेश (किसी भी भी त्रुटि संदेश के विभिन्न स्थानीयकरणों परीक्षण करने के लिए तय कर सकते हैं अगर मैं चाहते हैं, लेकिन दृश्य स्टूडियो मुझे ऐसा करने नहीं दूँगी:

[TestMethod] 
[ExpectedException(typeof(CriticalException), MyRes.MultipleOrganisationsNotAllowed)] 
public void GetOrganisation_MultipleOrganisations_ThrowsException() 

compil

An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute

किसी को भी पता है एक अपवाद संसाधन फ़ाइल से एक संदेश है कि के लिए परीक्षण करने के लिए कैसे: एर निम्न त्रुटि दे देंगे?


एक विकल्प पर विचार किया है मैं कस्टम अपवाद वर्गों का उपयोग करना है, लेकिन पर जैसे आधारित अक्सर सुना सलाह:

"Do create and throw custom exceptions if you have an error condition that can be programmatically handled in a different way than any other existing exception. Otherwise, throw one of the existing exceptions." Source

मैं सामान्य प्रवाह में अलग तरह से अपवाद को संभालने के लिए उम्मीद नहीं कर रहा हूँ (यह एक है महत्वपूर्ण अपवाद, इसलिए मैं पैनिक मोड में जा रहा हूं) और मुझे नहीं लगता कि प्रत्येक टेस्ट केस के लिए अपवाद बनाना सही काम है। कोई राय?

+3

संदेश पैरामीटर नहीं है फेंक दिया अपवाद के संदेश के खिलाफ चेक प्राप्त करें। –

उत्तर

7

बस एक राय है, लेकिन मैं कहूंगा कि त्रुटि पाठ: (अन्यथा आप हो सकते हैं

  • परीक्षण का हिस्सा है, जो मामले में संसाधन से यह हो रही है 'गलत' होगा लगातार के साथ उलझन संसाधन), इसलिए संसाधन को बदलने पर परीक्षण को अपडेट करें (या परीक्षण विफल रहता है)
  • परीक्षण का हिस्सा नहीं है, और आपको केवल यह ध्यान रखना चाहिए कि यह अपवाद फेंकता है।

ध्यान दें कि पहले विकल्प को आपको लोकेल के साथ चलाने की क्षमता के साथ कई भाषाओं का परीक्षण करने देना चाहिए।

कई अपवादों के लिए, मैं सी ++ भूमि से हूं, जहां बड़े हेराचियों में भार और अपवादों के भार (एक प्रति 'फेंक' कथन के बिंदु पर) स्वीकार्य है (यदि आम नहीं है), लेकिन नेट मेटाडेटा सिस्टम शायद इसे पसंद नहीं करता है, इसलिए वह सलाह।

+0

मैं एक साधारण प्रोसेस लागू करता हूं जो संसाधन फ़ाइल को पढ़ता है और संदेश को लिखा जा सकता है, आपकी विधि डी-मैप करने और मूल्यवान समय अपडेट करने के लिए एक शानदार तरीका है (हम जो अधिक से बचने की कोशिश कर रहे हैं) –

+0

@ मिकी: ठीक है तो, आप भाग्य में हैं: दूसरा जवाब वह है जो आप खोज रहे हैं! यदि आप * विशेष रूप से * एक ** इकाई ** चाहते हैं - परीक्षण करें कि यह वही संदेश पुनर्प्राप्त करता है, यह ठीक है, लेकिन मुझे यह पसंद है कि यह * सही * संदेश पुनर्प्राप्त करे। लेकिन अगर आपकी परियोजना अलग है, तो आप आसानी से एक अलग "सही" जवाब प्राप्त कर सकते हैं! –

+0

मैं डाटाबाउंड यूनिट परीक्षण का उपयोग करके पालन नहीं करता हूं, आप अपना केक रख सकते हैं और इसे भी खा सकते हैं। डेटाबेस में संसाधनों को मानचित्रित करें और परीक्षण में अपनी संदेश संस्कृति को मानचित्र करें, या इसके विपरीत। नहीं ? –

4

मुझे लगता है कि आप अपने परीक्षण कोड में केवल एक स्पष्ट प्रयास कर सकते हैं ताकि आपके लिए यह करने के लिए ExpectException विशेषता पर भरोसा किया जा सके। फिर आप कुछ सहायक विधि के साथ आ सकते हैं जो संसाधन फ़ाइल को पढ़ेगा और त्रुटि संदेश की तुलना उस अपवाद के साथ की जाएगी जो पकड़ा गया था।

3

आप बहुत अच्छा xUnit.Net परीक्षण लाइब्रेरी का उपयोग करने पर स्विच करते हैं (यदि वहाँ एक अपवाद तो परीक्षण का मामला एक असफल विचार किया जाना चाहिए नहीं था जाहिर है), तो आप कुछ इस तरह के साथ [ExpectedException] की जगह ले सकता:

[Fact] 
public void TestException() 
{ 
    Exception ex = Record.Exception(() => myClass.DoSomethingExceptional()); 
    // Assert whatever you like about the exception here. 
} 
1

मुझे आश्चर्य है कि क्या NUnit सादगी से दूर रास्ते को नीचे चला रहा है ... लेकिन यहां आप जाते हैं।

अपेक्षित एक्सेप्शन विशेषता में नए एन्हांसमेंट (2.4.3 और ऊपर?) आपको हैंडलर विधि के माध्यम से अपेक्षित अपवाद पर किए जाने वाले चेक पर अधिक नियंत्रण की अनुमति देता है। पृष्ठ के अंत में official NUnit doc page पर अधिक जानकारी ..

[ExpectedException(Handler="HandlerMethod")] 
public void TestMethod() 
{ 
... 
} 

public void HandlerMethod(System.Exception ex) 
{ 
... 
} 

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

+0

से सहमत हूं आपको नहीं लगता कि फेंकने वाले अपवाद से त्रुटि संवाद संदेश प्राप्त करने का तरीका अच्छा डिज़ाइन है? मैं इस धारणा के तहत था कि यह आम था, और यह त्रुटि पथ कोड को सरल बनाता है ... मुझे पता है कि मैं चीनी में एक संवाद नहीं देखना चाहता! –

+0

मैं NUnit फ्रेमवर्क संस्करण 2.6 का उपयोग कर रहा हूं और विशेषता [ExpectedException (हैंडलर = "हैंडलर मोड")] – dotnetguy

+0

@ मिशर्सड संकलित नहीं करता है - मेरा मानना ​​है कि संकलक आपको उस पर अधिक जानकारी देगा। आउटपुट फलक देखें - यह किस बारे में शिकायत कर रहा है? – Gishu

63

मैं एक विशेषता के बजाय एक सहायक विधि का उपयोग करने की सलाह दूंगा। कुछ इस तरह:

[TestMethod] 
public void GetOrganisation_MultipleOrganisations_ThrowsException() 
{ 
    OrganizationList organizations = new Organizations(); 
    organizations.Add(new Organization()); 
    organizations.Add(new Organization()); 

    var ex = ExceptionAssert.Throws<CriticalException>(
      () => organizations.GetOrganization()); 
    Assert.AreEqual(MyRes.MultipleOrganisationsNotAllowed, ex.Message); 
} 

यह भी लाभ यह सत्यापित करता है कि कि अपवाद लाइन पर फेंक दिया जाता है तो आपको उसे उम्मीद कर रहे थे है:

public static class ExceptionAssert 
{ 
    public static T Throws<T>(Action action) where T : Exception 
    { 
    try 
    { 
     action(); 
    } 
    catch (T ex) 
    { 
     return ex; 
    } 
    Assert.Fail("Exception of type {0} should be thrown.", typeof(T)); 

    // The compiler doesn't know that Assert.Fail 
    // will always throw an exception 
    return null; 
    } 
} 

तो फिर तुम इस तरह अपने परीक्षण कुछ लिख सकते हैं अपनी परीक्षण विधि में कहीं भी फेंक दिया।

+4

जाने के लिए रास्ता !!! मुझे इस तरह से और पसंद है। – argatxa

+1

क्या जवाब है! बहुत बढ़िया। यह भी मेरी मदद की :) – Learner

+0

महान समाधान जो मेरे लिए काम किया। –

13

अपेक्षित अपवाद संदेश तर्क अपवाद के संदेश के खिलाफ मेल नहीं खाता है। बल्कि यह वह संदेश है जो परीक्षण परिणामों में मुद्रित होता है यदि अपेक्षित अपवाद वास्तव में नहीं होता है।

0

मैं अपने आप पर एक ही समस्या को हल करने की कोशिश करते हुए इस प्रश्न में आया था। (मैं नीचे दिए गए समाधान का विस्तार करूंगा।)

मुझे कोड गंध होने के अपवाद संदेशों को अंतर्राष्ट्रीयकरण के बारे में गिशू की टिप्पणियों से सहमत होना है।

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

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

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

मेरे परीक्षण कोड तो बस करने पर निर्भर करता (mangling क्षमा ...):

[Test, 
    ExpectedException(typeof(System.ArgumentException), 
    ExpectedException=ProductExceptionMessages.DuplicateProductName)] 
public void TestCreateDuplicateProduct() 
{ 
    _repository.CreateProduct("TestCreateDuplicateProduct"); 
    _repository.CreateProduct("TestCreateDuplicateProduct"); 
} 
संबंधित मुद्दे

 संबंधित मुद्दे