इकाई परीक्षण के लिए क्या निर्धारित करना है और

Question

क्या नहीं है, मुझे अभी भी टेस्ट ड्राइव डेवलपमेंट को समझना है। मेरे पास एप्लिकेशन के उपयोगकर्ता पंजीकरण मॉड्यूल के लिए निम्नलिखित आवश्यकताएं हैं I

1. प्रणाली उपयोगकर्ता के firstname, lastname, ईमेल पता और वैकल्पिक रूप से कब्जा करना होगा, डाक पता
2. firstname और lastname
3. firstname और lastname खाली नहीं हो सकती
4. ईमेल पता वर्णमाला होना चाहिए एक वैध पता होना चाहिए और अनिवार्य है
5. डाक पता वैकल्पिक है।

जावा में उपरोक्त को लागू करने के लिए। मैं निम्नलिखित कोड लिखा है:

1. जावा ऊपर क्षेत्रों से युक्त और इसी getters और setters होने सेम
ऊपर क्षेत्रों के लिए
2. मान्यता एनोटेशन
3. एक उपयोगकर्ता
4. एक यूजर इंटरफेस को बचाने के लिए एक दाव उपयोगकर्ता विवरण दर्ज करने के लिए।

प्रश्न: उपर्युक्त कोड में से कौन सा कोड यूनिट परीक्षणों के साथ कवर किया जाना चाहिए? यानी बीन के गेटर और सेटर्स, सत्यापन एनोटेशन की उपस्थिति, उपयोगकर्ता को बचाने के लिए दाओ की क्षमता, यूआई में प्रासंगिक फॉर्म तत्वों की उपस्थिति।

Answer 1

मैं चीजें हैं जो मैं कारण के लिए परीक्षण लिखने "मैं इस गलत किया है सकते हैं?"। इसका मतलब है कि मैं आपूर्ति की गई पुस्तकालयों की जांच करने के लिए परेशान नहीं हूं - केवल उनकी विन्यास ही।

गेटर्स और सेटर्स - निश्चित रूप से नहीं। मैं उन्हें उत्पन्न करने के लिए ग्रहण का उपयोग करता हूं, यह परीक्षण के लायक नहीं है।

सत्यापन के लिए एनोटेशन - मैं परीक्षण नहीं है कि वे, उदाहरण के लिए, सही ढंग से एक अशक्त जांच लागू, मैं पर भरोसा करते हैं कि वे क्या यह टिन पर कहते हैं, लेकिन मैं उन्हें की उपस्थिति का परीक्षण होगा। क्या सही क्षेत्र में उन्हें है? और अगर मैंने उन्हें regexp के साथ कॉन्फ़िगर किया है, तो मैं परीक्षण करूंगा कि मुझे regexp सही मिला है।

एक और उदाहरण, अगर मैं अपने पीओजेओ को हाइबरनेट के साथ स्टोर करता हूं। मैं यह नहीं देखता कि Session.save(myObj) काम कर रहा है, लेकिन सामान जो मैंने लेनदेन की सीमाओं और मैपिंग कॉन्फ़िगरेशन (सभी फ़ील्ड सहेजे गए हैं) जैसे

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

Answer 2

एक बात के लिए मुझे टीडीडी के बारे में पता है, आपने कभी भी कोड कभी नहीं लिखा है।

आप पहली बार एक परीक्षण लिखते हैं, क्योंकि आपका परीक्षण विफल हो जाता है, आप इसे ठीक करने के लिए कोड लिखते/उत्पन्न करते हैं और उसके बाद उस कार्यक्षमता को तोड़ने के लिए और अधिक परीक्षण लिखते हैं जिसे आप प्राप्त करना चाहते हैं और इसके लिए मूल कोड लिखना चाहते हैं।

यदि आपके पास 100% कोड कवरेज है तो इसका सर्वोत्तम होगा।

कैसे आप TDD साथ अपनी परियोजना के साथ शुरू करने की आवश्यकता के लिए विकिपीडिया का संदर्भ लें - http://en.wikipedia.org/wiki/Test-driven_development