यूनिट परीक्षण डीएओ, क्या मैं इसे सही कर रहा हूं?

Question

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

मैं एक छोटा ब्लॉग बना रहा हूं। मैं नकली वस्तुओं के लिए EasyMock का उपयोग कर रहा हूँ।

The test case

The PostDAO

The Post Bean

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

यहाँ मेरी कोड है। अग्रिम में धन्यवाद!

Answer 1

यहां मिनी-कोड समीक्षा के लिए कुछ विचार दिए गए हैं। उन्हें लायक के लिए ले जाएं, बस अपराध न करें:

1. आपको जुनीट 4.x मुहावरे का उपयोग करना चाहिए। टेस्टकेस बढ़ाने की जरूरत नहीं है। "@ टेस्ट" एनोटेशन का प्रयोग करें।
2. डीएओ के लिए कनेक्शन का मज़ाकिया हास्यास्पद है। वास्तविक कनेक्शन का उपयोग करें, डेटाबेस से कनेक्ट करें, और वास्तविक क्वेरी चलाएं। इसके बिना, आपका डीएओ परीक्षण बेकार है।
3. डीएओ का परीक्षण करते समय आप सबसे महत्वपूर्ण विचारों में से एक खो रहे हैं: डेटा। लिखित के रूप में आपका सेट अप मदद नहीं कर रहा है। आप वास्तव में क्या चाहते हैं परीक्षण डेटा के साथ डेटाबेस को बीज करना, अपने परीक्षण चलाएं, और फिर पूरी चीज को वापस रोल करें ताकि ऐसा हो जैसे आप कभी नहीं थे। परीक्षण डेटाबेस के साथ सबसे बड़ी समस्याओं में से एक यह सुनिश्चित कर रहा है कि आपका परीक्षण डेटा उपलब्ध है। चीजों को एक लेनदेन के रूप में करना इसे पूरा करने का सबसे अच्छा तरीका है।
4. आप "खुश पथ" का परीक्षण कर रहे हैं, लेकिन आप किसी भी किनारे की स्थिति का प्रयास नहीं कर रहे हैं। प्रत्येक एक अलग परीक्षण कॉल होना चाहिए। मैं आपकी स्कीमा नहीं देख सकता, लेकिन यदि आपकी तालिका किसी भी पैरामीटर के लिए शून्य मानों को प्रतिबंधित करती है, या एक अद्वितीय बाधा उत्पन्न करती है, तो मैं प्रत्येक के लिए उस तथ्य को प्रदर्शित करने के लिए अलग-अलग परीक्षण लिखूंगा और साबित करूँगा कि यह ठीक से काम कर रहा है। उन्हें संभालने के लिए सही दृष्टिकोण क्या है? अपवाद फेंको? आपको इसके बारे में सोचना चाहिए।
5. आपकी त्रुटि प्रबंधन खराब है। कंसोल को एक संदेश प्रिंट करना सहायक नहीं है। आपको log4j का उपयोग करके कम से कम लॉग इन करना चाहिए।
6. आपकी createPost विधि ऑफ़-बेस दिखाई देती है। आप दो पैरामीटर पास करते हैं और एक पोस्ट वापस करते हैं। आमतौर पर ओआरएम समाधान के साथ, जैसे हाइबरनेट, आपके पास पहले से ही ऑब्जेक्ट्स होंगे।
7. डीएओ कनेक्शन बनाना नहीं चाहिए। उन्हें एक सेवा परत द्वारा पारित किया जाना चाहिए जो काम और लेनदेन की इकाइयों के बारे में जानता है।
8. जिसमें से बात करते हैं, आपके पास कोई प्रतिबद्ध/रोलबैक तर्क नहीं है। भगवान का शुक्र है, क्योंकि यह डीएओ में नहीं है, लेकिन मैं शर्त लगाऊंगा कि आपने इसके बारे में सोचा नहीं है।
9. ऐसा लगता है कि आपका मतलब "आईडी" प्राथमिक कुंजी होना है, लेकिन मुझे वास्तव में आपके INSERT के बाद डेटाबेस से बाहर खींचने और ऑब्जेक्ट को पॉप्युलेट करने के लिए कुछ भी नहीं दिखता है। यह अपने आप नहीं होगा।
10. Spring's जेडीबीसी समर्थन देखकर आप बहुत कुछ सीखेंगे। मैं इसकी सिफारिश करता हूँ। उन्होंने यह कभी भी आपके से बेहतर किया है।

Answer 2

आपके यूनिट परीक्षण से संबंधित नहीं है, लेकिन मैं createPost (..) खराब अभ्यास में आपके अपवाद हैंडलिंग पर विचार करता हूं। अपवाद पूरी तरह से निगल नहीं है, लेकिन एक पोस्ट ऑब्जेक्ट लौट रहा है जैसे सब कुछ ठीक हो गया है, यह एक अच्छा विचार नहीं है। देखें Error Hiding

Answer 3

मुझे लगता है कि यह आम तौर पर ठीक है (मैं इसे दोहराने से बचने के लिए अपने एसक्यूएल के लिए एक स्ट्रिंग स्थिरता पेश करता हूं, बीटीडब्ल्यू)।

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

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

public void testPostDAO() { 
     try { 
       new PostDAO(null); 
       fail("Expected IllegalArgumentException"); 
     } catch (IllegalArgumentException ex) {} 
     new PostDAO(connectionMock); 
} 

कुछ लोग इसकी छोटीता के कारण new PostDAO(null) का परीक्षण करने के लिए ऑब्जेक्ट करते हैं। मैं असहमत हूं। परीक्षण लिखने के कारणों में से एक यह सुनिश्चित करना है कि व्यवहार तब तक नहीं बदलेगा जब तक आप इसे तक नहीं देखते। तो उपर्युक्त अच्छा है - मैं इसे दो स्पष्ट परीक्षणों में विभाजित कर दूंगा।

Answer 4

अपने परीक्षण की शुरुआत से कुछ सोचा:

public void testPostDAO() { 
       try { 
         new PostDAO(null); 
         fail("Expected IllegalArgumentException"); 
       } catch (IllegalArgumentException ex) {} 
       new PostDAO(connectionMock); 
     } 

परिवर्तन अनिवार्य नहीं कर रहे हैं और किसी ने कहा कि कर सकते हैं कि वे गलत कर रहे हैं, लेकिन यह मेरी राय है के बाद:

1. स्प्लिट सामान्य मामले और त्रुटि - - परीक्षण के तहत आपकी इकाई के दो अलग-अलग व्यवहार हैं

2. इसे और कुछ स्पष्ट करने के लिए नाम बदलें - यह निर्दिष्ट करने के लिए कि आप क्या कर रहे हैं - उदाहरण के लिए testPostDAOWithNullArg

3. कोई अपवाद उठाए जाने पर आपका परीक्षण विफल रहता है, तो कैसे WeryBadStange अपवाद उठाया जाएगा? आप इसे पकड़ नहीं पाएंगे, और असफल लाइन नहीं मिलेगा।

Answer 5

• आप यहां क्या परीक्षण कर रहे हैं?आईएमएचओ यहां एकमात्र चीज है जो आपके एसक्यूएल कमांड है क्योंकि आपके डीएओ में परीक्षण करने के लिए कोई विशिष्ट तर्क नहीं है।
• "नया पोस्टडाओ (शून्य)" जैसे इनिट कोड का परीक्षण करना इतना आसान है जब यह बेकार है।
• मैं वास्तविक डेटाबेस के खिलाफ परीक्षण करने के लिए स्मृति मोड में hsqldb और कम नकली कोड होगा।
• क्या कोई कारण है कि आप जुनीट 3 में टेस्टकेस को विस्तारित करने के बजाय एनोटेशन का उपयोग करके जुनीट 4 टेस्ट स्टाइल का उपयोग क्यों नहीं कर सकते?

Answer 6

आपके यूनिट टेस्ट में कोई बात नहीं है। आप क्या परीक्षण कर रहे हैं आपके पास क्या तर्क है? यह क्या साबित करता है?

मैं देख सकता हूं कि आपके परीक्षण कुछ भी साबित नहीं करते हैं। मिस टाइप डालने से आपका परीक्षण पास हो जाएगा। अवैध तर्क भी।

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