अपवादों के आसपास इकाई परीक्षण क्षेत्रों का सही तरीका क्या है

Question

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

ऑब्जेक्ट्स को मॉक करने का एकमात्र तरीका यह है कि अपवाद को फेंक दिया जा सकता है? यह थोड़ा सा व्यर्थ लगता है। शायद 100% कोड कवरेज नहीं प्राप्त करना स्वीकार करना बेहतर है?

धन्यवाद, दान

Answer 1

आमतौर पर जब निम्न स्तर के अपवादों में चलते हैं, जैसे जावा में IOException या SQLException, तो मैं उन्हें RuntimeException को विस्तारित अपवाद में लपेटता हूं। मुझे लगता है कि इस व्यवहार का परीक्षण करना काफी महत्वपूर्ण है क्योंकि अन्यथा अपवाद को गलती से निगलने की बहुत ही खराब संभावना है।

इसलिए यदि आप कम स्तर के अपवाद को फेंकते हैं तो वास्तव में कुछ करते हैं, तो मैं उनका परीक्षण करने की सलाह देता हूं।

संपादित करें: जोड़ा गया उदाहरण।

public void store(User user) { 
    try { 
     userDao.store(user); 
    } catch (IOException e) { 
     // Logging, perhaps some logic. 
     throw new ServiceException(e); 
    } 
} 

@Test(expected = ServiceException.class) 
public void Store_Fail() { 
    UserDao userDaoMock = createMock(UserDao.class); 
    User user = // Create test user. 
    userDaoMock.store(user); 
    replay(userDaoMock); 
    userService.store(user); 
    verify(userDaoMock); 
} 

यहां परीक्षण करने के लिए बहुत कुछ नहीं है, लेकिन अगर तर्क को सेवा अपवाद के लिए जरूरी है तो इसका परीक्षण क्यों न करें?

Answer 2

एक आम बात एक 100% कवरेज लक्ष्य निर्दिष्ट किया जाता है परीक्षण से जितना संभव हो उतना कोड को कवर करने और कोड की समीक्षा से शेष कुछ percents कवर करने के लिए है जब।

Answer 3

ऑब्जेक्ट्स को मॉक करने का एकमात्र तरीका यह है कि अपवाद को फेंक दिया जा सकता है?

मेरा मानना ​​है कि यह सबसे आसान तरीका होगा, लेकिन आप एक स्टब भी कर सकते हैं (उर्फ ऑब्जेक्ट जो वास्तविक वस्तु को बढ़ाता है, और प्रत्येक बार अपवाद फेंकने की तरह व्यवहार करता है)। या आप एओपी का उपयोग कर सकते हैं, लेकिन मुझे लगता है कि easymock या jmock जैसी लाइब्रेरी का उपयोग करने का सबसे आसान तरीका होने जा रहा है।

यह थोड़ा सा व्यर्थ लगता है। शायद 100% कोड कवरेज नहीं प्राप्त करना स्वीकार करना बेहतर है?

जब भी मैं इस विषय पर बात करता हूं, मैं लोगों की मानसिकता को कवरेज के एक निश्चित प्रतिशत के बारे में चिंता करने से रोकता हूं, और इसके बजाय आपको बेहतर डेवलपर बनाने के लिए टूल के रूप में प्रतिशत का उपयोग करने के लिए पसंद करता हूं। 100% कवरेज या 50% कवरेज रखने का एक और तरीका यह नहीं है कि आपका कोड अच्छी तरह से लिखा गया है या यहां तक ​​कि काम कर रहा है लेकिन कोड कवरेज का उपयोग मुख्य संकेतक के रूप में करते समय जब आप कोड विकसित कर रहे हैं कि आप लिखने के परीक्षण आदि पर slacking रहे हैं ... है एक अच्छा विचार।

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

यह सुनिश्चित करने के लिए कि 100% क्रोध नहीं है, मैं कहूंगा कि यह इसके लायक नहीं है। आपको अपने लिए एक अच्छा आराम स्तर मिलना चाहिए (शायद 80%, शायद 90%) और इसके साथ चिपके रहें। लेकिन मैं इसे परीक्षण के प्रकारों (जैसे परीक्षण अपवाद तर्क) पर आधारित नहीं करता हूं, यह केवल कुल कवरेज पर आधारित होना चाहिए और एक संकेतक के रूप में देखा जाना चाहिए कि जब आप कोड करते हैं तो आप अपने परीक्षण नहीं लिख रहे हैं।