मेरे जुनीट परीक्षणों में अपवाद-संचालन करने के बजाय, मैं बस अपने परीक्षण विधियों को ... throws Exception के साथ घोषित करता हूं?क्या यह ज्यूनिट परीक्षण में सभी अपवादों को फेंकने का बुरा अभ्यास है?
मैंने ऐसा करना शुरू कर दिया और मुझे कोई कारण नहीं दिख रहा कि मुझे और अधिक विशिष्ट क्यों होना चाहिए।
यूनिट-टेस्ट का मुख्य पहलू यह है कि आप जितनी जल्दी हो सके अपने उत्पादन कोड में बग को अलग/हल करने में मदद करें।
उस अर्थ में: आप अन्य तरीकों से बुलाए जाने के लिए अपने @ टेस्ट विधियों को नहीं लिखते हैं। आप उन्हें लिखते हैं ताकि जुनीट फ्रेमवर्क उन्हें चला सके।
और आमतौर पर, जब वह परीक्षण अपवाद फेंकता है; इसे पकड़ने में कोई बात नहीं है (जब तक इसकी उम्मीद नहीं की जाती है, और आप उस अपवाद पर आगे की जांच करना चाहते हैं)।
इस प्रकार: पकड़ने वाले ब्लॉक नहीं; और इसके बजाय आपके टेस्ट विधि हस्ताक्षरों के संभावित फेंक कारण जोड़ना सभी मामलों के 99.9 99% में सही उत्तर है। या शायद 100%; क्योंकि मुझे एक अच्छा काउंटर उदाहरण नहीं मिल रहा है।
लेकिन मैं जल्दी से throws Exception का उपयोग करने के बारे में सावधान रहूंगा। आप अभी भी अपने कोड को "विशिष्ट" के रूप में संभव बनाना चाहते हैं; throws ThatExceptionThatCanReallyBeThrown के लिए बेहतर जाना है। और जब वह सूची बहुत अधिक बार बढ़ती है ... तो आप उस तरफ बेहतर तरीके से पालन करते हैं और जांचते हैं कि आपके उत्पादन कोड में आपकी फेंक सूची किसी भी तरह से "छंटनी" होनी चाहिए।
संपादित करें: संभवतः समझने की मुख्य बात यह है कि: आपके प्रत्येक परीक्षण के लिए, आपके पास सटीक क्या होगा, इसकी अपेक्षा है। यही कारण है कि विधि चाहिए या तो:
@Test(expected=...) बातऔर बस अपने परीक्षा पद्धति हस्ताक्षर पर throws X, Y डाल गोलियों 2 और 4
मुझे उन 1% मामलों में से एक में दिलचस्पी होगी, जहां यह खराब अभ्यास होगा। – codepleb
मुझे लगता है: यह उन मामलों में होगा जब आप कुछ अपवाद होने की उम्मीद करते हैं और आपको पकड़े गए अपवाद ऑब्जेक्ट के गुणों की जांच करने की आवश्यकता होती है। अन्यथा, आप वास्तव में अपनी विधि पर '@ टेस्ट (अपेक्षित = जो भी। क्लास)' डाल देंगे ... और अपनी फेंक सूची पर जो भी हो। – GhostCat
ठीक है। तो मूल रूप से यदि आप कस्टम अपवादों को लागू करते हैं जिन्हें आप जांचना नहीं चाहते हैं। उचित लगता है। :) धन्यवाद – codepleb
को संबोधित @GhostCat जवाब के अलावा के सीधे आगे तरीका है कहना चाहता हूँ - JUnit Rules नामित अच्छा सुविधा है। यह अपवादों के परीक्षण के लिए उपयुक्त है और शायद @Test(expected=Whatever.class) से बेहतर है।
उदाहरण उपयोग:
public class Test {
@Rule
public final ExpectedException thrown = ExpectedException.none();
private MyService myService;
@Before
public void setUp() {
myService = new MyService();
}
@Test
public void exceptionTest() throws MyException {
thrown.expect(MyException.class);
thrown.expectMessage("my description");
myService.create("bad argument"); //throws MyException("my description")
}
}
अच्छा एक; अभी तक खुद का उपयोग नहीं किया है। – GhostCat
कुछ स्थितियों में यह समझ में आता है। दूसरों में, यह – ControlAltDel
@ControlAltDel नहीं है: क्या आपको ऐसी स्थिति याद है जहां यह समझ में नहीं आया? – codepleb
थोड़ी देर बाद स्वीकार करने के लिए बहुत बहुत धन्यवाद; मैंने कल 200+ टोपी मारा; और सुबह की स्वीकृति हमेशा एक अच्छी शुरुआत होती है ;-) – GhostCat