2009-01-15 22 views
5

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

उत्तर

7

मान लें कि मैं अपने स्वादिष्ट Pie ऑब्जेक्ट्स को सेंकने के लिए Oven नामक कक्षा को कोड कर रहा हूं। इस प्रकार मैं यूनिट-टेस्ट ऑर्डर के माध्यम से कदम उठाता हूं:

  1. ऑब्जेक्ट को तुरंत चालू करने के लिए मुझे क्या करने की आवश्यकता है? इस मामले में यह संभवतः Oven oven = new Oven(); होगा, इस के लिए कोई परीक्षण नहीं, मुझे लगता है।
  2. मैं वस्तु के उपयोग के लिए कैसे तैयार करूं? oven.turnOn(int degrees) अच्छा लगता है, मैं यह करूँगा। मैं इसे कैसे देखूं? oven.getTemperature() बेहतर बनाएं। एक स्पष्ट परीक्षण है।
  3. ठीक है, ओवन अब काफी गर्म है और मैं अपना Pie सेंकना चाहता हूं। इसके लिए मुझे oven.bake(Pie p) की आवश्यकता है, इसलिए मैं इसे बनाउंगा। लेकिन अब क्या? मैं यह जांचना चाहता हूं कि पाई तैयार है या नहीं, oven.isPieReady() होने के बजाय मुझे लगता है कि oven.pastryStatus() जो "ओवन में कुछ भी नहीं", "कच्चा", "लगभग किया गया", "पकाया गया" और "charred" अच्छी चीजें देता है और सामान्य रूप से oven.isPieReady() से अधिक विस्तार योग्य हो तो मैं ऐसा करूँगा।

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

+0

+1 अच्छी तरह से किया गया, सर – annakata

+0

क्या होता है यदि आप बिल्ली सी को ओवन में डालते हैं? एक "charred" पाई, या एक पाई ओवन के लिए तैयार नहीं है के बारे में क्या? सीमा और अमान्य इनपुट परीक्षण महत्वपूर्ण हैं। – Tester101

+0

वे चश्मे को परिष्कृत करने वाले व्यक्तिगत परीक्षण हैं, उदाहरण के लिए testCantBakeACat() :) लेकिन हाँ, सीमा और अमान्य इनपुट परीक्षण वहां सबसे महत्वपूर्ण लोगों में से एक हैं और उन्हें याद नहीं किया जाना चाहिए। – Esko

0

मैं सबसे स्वतंत्र/निम्न-स्तरीय कार्यक्षमता के लिए इकाइयों का एक सेट तैयार करूंगा। एक बार जब आप उन कक्षाओं को हर परीक्षा उत्तीर्ण कर लेते हैं, तो आप आगे बढ़ सकते हैं, मानते हैं कि वे अधिक निर्भर कार्यक्षमता के द्वारा बुलाए जाने पर काम करेंगे।

1) सीमा ऑब्जेक्ट (विन/WebForms, CustomControls आदि) की पहचान:

0

ये सामान्य दिशा निर्देशों मैं इकाई परीक्षण को प्राथमिकता देने के लिए उपयोगी पाते हैं।

2) नियंत्रण ऑब्जेक्ट (व्यापार परत वस्तुओं की पहचान)

3) ईकाई परीक्षण लिखें नियंत्रण सीमा वस्तुओं द्वारा लाया सार्वजनिक तरीकों वस्तुओं के लिए ही। इस तरह आप सुनिश्चित होंगे कि आप अपने ऐप के मुख्य कार्यात्मक पहलुओं को कवर कर रहे हैं।

आप इन नियमों का उपयोग अपने यूनिट परीक्षण को प्राथमिकता देने के लिए कर सकते हैं - फिर यदि आपको अन्य सामानों का माइक्रो-टेस्ट करने की आवश्यकता है तो आप अपनी आवश्यकताओं के आधार पर भी ऐसा कर सकते हैं।

1

जब लागू करने के लिए परीक्षण की एक सूची के साथ सामना, आप श्रेणियों

  1. तुच्छ परीक्षण करने के लिए होगा, लेकिन क्या आप वाकई यह किया प्राप्त कर सकते हैं कर रहे हैं।
  2. गैर-तुच्छ लेकिन आप इसे के उचित रूप से आत्मविश्वास से प्राप्त कर रहे हैं।
  3. गैर-तुच्छ लेकिन मुश्किल-बिल्कुल का कोई संकेत नहीं है।

ऐसे परिदृश्य में, श्रेणी 2 बाल्टी से एक चुनें क्योंकि यह निवेशित समय की प्रति इकाई अधिकतम ज्ञान/सीखने के साथ प्रदान करेगा।इसके अलावा यह आपको अधिक कठिन श्रेणी 3 परीक्षणों तक पहुंचने के लिए रोलिंग और आत्मविश्वास बढ़ाएगा।

मुझे लगता है कि मुझे यह TDD By Example - केंट बेक से मिला है। यदि आपके पास समय है तो एक नज़र डालें .. अनुशंसित।

+0

दिलचस्प थीं। अपने अनुभव में मैंने पाया कि छोटे प्रयासों के लिए बहुत सारी बग मोड़ने में मामूली परीक्षण काफी प्रभावी हैं, लेकिन विचार के लिए अच्छा खाना। +1 – peterchen

+0

मैं नहीं कह रहा हूं कि 'छोटे परीक्षणों को अनदेखा करें' .. सभी 3 श्रेणियों की आवश्यकता है। :) बस उन्हें लेने का आदेश। श्रेणी 2 एक हद तक 'युद्ध के धुंध' (गेमिंग अवधि का उपयोग करने) को साफ़ करने में मदद करता है जबकि एक ही समय में आपको टीडीडी कोडर के ब्लॉक से फंसे या फंसने की अनुमति नहीं मिलती है। – Gishu

1

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

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

याद रखें कि परीक्षण का लक्ष्य न केवल व्यवहार को सत्यापित करने के लिए है, बल्कि आपको परीक्षण के तहत प्रकार के इंटरफ़ेस का उपयोग करने देता है। यदि परीक्षण लिखना गलत लगता है, तो आपको शायद इंटरफ़ेस को बदलने की आवश्यकता है।

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

संबंधित मुद्दे