एक विधि/कक्षा कोडिंग शुरू करने से पहले कितनी यूनिट-परीक्षण?

Question

मैं टीडीडी सिद्धांतों का उपयोग करके कोडिंग करने के लिए (कम से कम कोशिश कर रहा हूं) शुरू कर रहा हूं और मेरे पास यह प्रश्न है: वास्तव में कोडिंग शुरू करने से पहले मुझे कितने परीक्षण लिखने की आवश्यकता है?

उदाहरण के लिए एक hypothetically Math कक्षा और एक विधि Divide(int a, int b) ले लो।

क) पहले कोडिंग Math शुरू मैं पूरी तरह से Math वर्ग (Sum, Average, ...) के सभी तरीकों का परीक्षण करने के है?

बी) क्या मुझे विधि को कोडिंग शुरू करने से पहले शून्य से विभाजन के लिए उदाहरण के लिए Divide विधि का पूरी तरह से परीक्षण करना है?

सी) या मैं एक सरल परीक्षण दावा कर सकता हूं और यह सत्यापित कर सकता हूं कि यह विफल रहता है, कोड लिखता है और जांचता है कि यह ठीक है, विधि के प्रत्येक दावे के लिए प्रक्रिया को दोहरा रहा है?

मुझे लगता है कि विकल्प सी) सही है, लेकिन मुझे इसका कोई जवाब नहीं मिला (मैंने कुछ खोज की लेकिन मुझे एक निश्चित उत्तर नहीं मिला)।

Answer 1

आपका विकल्प सी पूरी तरह से टीडीडी पुस्तक द्वारा प्रस्तुत करता है।

आप उस कक्षा की एक विशेषता का उपयोग करने में एक असफल परीक्षण लिखते हैं जिस पर आप काम कर रहे हैं और फिर उस परीक्षा पास करने के लिए केवल पर्याप्त कोड लिखें। फिर आप अगले टेस्ट के लिए इसे फिर से करें।

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

आप लाल-हरे-रिफैक्टर फैशन में काम करना समाप्त करना चाहते हैं, ताकि समय-समय पर आप अपने कोड और उन स्थानों के लिए अपने परीक्षणों पर वापस जाएं जहां आप चीजों को बेहतर डिजाइन में दोबारा कर सकते हैं।

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

इस पर विकिपीडिया लेख वास्तव में काफी अच्छा है। http://en.wikipedia.org/wiki/Test-driven_development

Answer 2

खैर आप शायद अब

@Test 
public void testDivide() { 
    Math math = new Math(); 
    int result = math.divide(20,2); 
    Assert.assertNotNull(result); 
} 

यह है कि, लिख सकते हैं जब आप चलाने के इस अपने परीक्षण आप अपने Math.divide विधि ठीक तो असफल हो जायेगी। और अगले चरण

में मामलों को जोड़ें यह एक बहुत ही आदर्श तरीका है लेकिन हर कोई जानता है कि यह हमेशा इस तरह से नहीं होता है।

Answer 3

पहली चीज जो आप करना चाहते हैं वह प्रत्येक विधि के लिए एक विनिर्देश लिखें जिसे आप कार्यान्वित करना चाहते हैं। आपके विनिर्देशन में, आपको जितनी चाहें उतनी कोने के मामलों को संबोधित करने की आवश्यकता है, और उन मामलों को निष्पादित करते समय आपके तरीके के व्यवहार को परिभाषित करना चाहिए।

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

फिर आप सब कुछ दस्तावेज करते हैं (विशेष रूप से कोने के मामलों को संभालने के लिए आपके तर्क)।

Answer 4

दूसरों की तरह उल्लेख किया गया है, आपका विकल्प सी ऐसा करने के लिए शुद्ध टीडीडी तरीका होगा। विचार है कि अपने कोड को छोटे लाल-हरे-रिफैक्टर वृद्धि में बनाएं। इसका एक अच्छा सरल उदाहरण रॉबर्ट मार्टिन का Bowling Kata है।

Answer 5

"इकाई" की परिभाषा not universal है, कभी-कभी इकाई कक्षा होती है, कभी-कभी यह एक विधि हो सकती है। तो कोई वास्तविक सार्वभौमिक जवाब नहीं है।

इस विशेष मामले में, मैं इकाई को एक विधि मानता हूं ताकि कोडिंग शुरू करने से पहले सभी विधियां नहीं होंगी। इसके बजाए, मैं विधियों के बाद विधियों, वृद्धिशील तरीके से काम करता हूं। यह एक को समाप्त करता है)।

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

यदि आपका परीक्षण पूर्ण नहीं है, तो आप वास्तव में अपनी इकाई के साथ नहीं कर रहे हैं भले ही परीक्षण पास हो रहा हो और मुझे वास्तव में बिंदु दिखाई नहीं दे रहा है। मुझे लगता है कि यह सी है)।

तो मेरी पसंद बी) होगी।

Answer 6

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