2009-06-01 13 views
14

कहां से शुरू करें, इसलिए मैंने यूनिट परीक्षण कुछ किया है, और अनुभव लेखन परीक्षण हैं, लेकिन मैंने टीडीडी को डिज़ाइन टूल के रूप में पूरी तरह से गले लगा लिया नहीं है।टीडीडी: पहला टेस्ट

मेरा वर्तमान प्रोजेक्ट मौजूदा सिस्टम को फिर से काम करना है जो कंपनियों की असेंबली प्रक्रिया के हिस्से के रूप में धारावाहिक संख्या उत्पन्न करता है। मौजूदा सिस्टम को देखने के कारण मुझे वर्तमान प्रक्रिया और वर्कफ़्लो की समझ है। मेरे पास नई आवश्यकताओं की एक सूची है और वे कार्य प्रवाह को संशोधित करने जा रहे हैं।

मुझे लगता है कि मैं प्रोग्राम लिखना शुरू करने के लिए तैयार हूं और मैंने अंततः शुरुआत से अंत तक टीडीडी करने के लिए मजबूर करने का फैसला किया है।

लेकिन अब मुझे नहीं पता कि कहां से शुरू करना है। (मुझे यह भी आश्चर्य है कि क्या मैं टीडीडी प्रक्रिया को धोखा दे रहा हूं, पहले से ही उपयोगकर्ता के लिए कार्यक्रम प्रवाह का विचार है।)

उपयोगकर्ता प्रवाह वास्तव में धारावाहिक है और केवल चरणों की एक श्रृंखला है। उदाहरण के लिए, पहला कदम होगा:

  • उपयोगकर्ता एक विनिर्माण आदेश संख्या सबमिट करता है और माल की कि आदेश बिल की serializable हिस्सा नंबरों की सूची प्राप्त करता

अगले कदम है जब उपयोगकर्ता शुरू कर दिया है भाग संख्याओं में से एक का चयन करता है।

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

// This isn't what I'd want my code to end up looking like 
// but it is the simplest statement of what I want 
IList<string> partNumbers = GetPartNumbersForMfgOrder(string mfgOrder); 

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

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


एक साइड नोट के रूप में ... क्या आप कहानियों का उपयोग करेंगे?

मैं एक MFG आदेश पर भाग नंबरों की सूची प्राप्त करने के लिए तो यह है कि मैं जो एक क्रमानुसार करने

सच्चा होना करने के लिए चुन सकते हैं चाहते हैं एक कोडांतरक के रूप में, एक कोडांतरक कहना कभी नहीं होगा कि।

एक कोडांतरक मैं एक सीरियल नंबर साथ भागों चिह्नित करने के लिए तो यह है कि मैं MFG आदेश पर आपरेशन समाप्त कर सकते हैं

उत्तर

15

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

  1. उपयोगकर्ता कहानी और व्यापार मूल्य है कि यह लाता है परिभाषित करें "
  2. यूआई के साथ शुरू करें। तीन फ़ील्ड के साथ एक बहुत ही सरल पृष्ठ बनाएं (इसे एक वेब ऐप मानें): लेबल, सूची और बटन। यह काफी अच्छा है, है ना? उपयोगकर्ता सूची की प्रतिलिपि बना सकता है और आविष्कार प्रणाली को भेज सकता है।
  3. एमवीसी की तरह अपने desig आधार के लिए एक पैटर्न का प्रयोग करें।
  4. यूआई से बुलाए जाने वाले आपके नियंत्रक विधि के लिए एक परीक्षण परिभाषित करें। आप यहां परीक्षण कर रहे हैं कि नियंत्रक काम करता है, न कि डेटा सही है: Assert.AreSame(3, controller.RetrieveParts(mfgOrder).Count)
  5. कुछ सुनिश्चित करने के लिए नियंत्रक का एक सरल कार्यान्वयन लिखें: return new List<MfgOrder>{new MfgOrder(), new MfgOrder(), new MfgOrder()}; आपको MfgOrder के लिए कक्षाएं लागू करने की भी आवश्यकता होगी, उदाहरण के लिए ।
  6. अब आपका यूआई काम कर रहा है! गलत तरीके से काम करना, लेकिन काम करना। तो चलिए नियंत्रक को सेवा या डीएओ से डेटा प्राप्त करने की उम्मीद करते हैं। परीक्षण मामले में एक नकली डीएओ ऑब्जेक्ट बनाएं, और एक अपेक्षा जोड़ें कि "partsDao.GetPartsInMfgOrder()" विधि कहा जाता है।
  7. विधि के साथ डीएओ कक्षा बनाएँ। नियंत्रक से विधि को बुलाओ। आपका नियंत्रक अब किया गया है।
  8. डीएओ का परीक्षण करने के लिए एक अलग परीक्षण बनाएं, अंत में यह सुनिश्चित कर लें कि यह डीबी से उचित डेटा लौटाता है।
  9. इसे तब तक जारी रखें जब तक आप इसे पूरा नहीं कर लेते। थोड़ी देर के बाद, आप इसका इस्तेमाल करेंगे।

मुख्य बिंदु यहां एप्लिकेशन को बहुत छोटे हिस्सों में अलग कर रहा है, और व्यक्तिगत रूप से उन छोटे हिस्सों का परीक्षण कर रहा है।

1

मुझे लगता है कि आप चाहते हैं के रूप में: सभी एक कोडांतरक चाहता MFG आदेश पर संचालन पूरा होने तक है एक अच्छी शुरुआत लेकिन इसे इस तरह से बिल्कुल नहीं देखते हैं। परीक्षण जो अधिक परीक्षणों को जन्म देने वाला है, मुझे समझ में आता है जैसे कि आप इसके बारे में सोचते हैं, क्या आप जानते हैं कि विनिर्माण आदेश संख्या या भाग संख्या अभी तक क्या है? आपको उन लोगों को बनाना होगा जो संभवतः अन्य परीक्षणों की ओर ले जाते हैं लेकिन आखिरकार आप विश्वास करते हैं कि मैं इस बात पर विश्वास करूँगा।

यहाँ एक कहानी है कि टूट का एक सा की आवश्यकता हो सकती है: एक उपयोगकर्ता मैं एक विनिर्माण आदेश संख्या सबमिट करें और सामग्री की है कि आदेश बिल की serializable हिस्सा नंबरों की सूची प्राप्त करना चाहते हैं के रूप में

मुझे लगता है कि चीजों को बार-बार छोटे टुकड़ों में तोड़ना है जो इसे पूरी चीज बनाना है। वह "विभाजन और जीत" तकनीक कई बार आसान है। ;)

+0

आप कहानी, लाभ का तीसरा हिस्सा भूल गए। आपके पास कार्यान्वयन विवरण भी है, जो कोई व्यावसायिक लाभ नहीं लेता है (धारावाहिक)। मैं कहूंगा कि एक बेहतर कहानी कुछ ऐसा होगा जैसे "एक उपयोगकर्ता के रूप में मैं एक विनिर्माण आदेश संख्या और उस आदेश के भाग संख्याओं की एक सूची जमा करना चाहता हूं ताकि मैं सूची सूची में सूची भेज सकूं"। –

+0

उस संदर्भ में Serializable कार्यान्वयन नहीं है, यह एक डोमेन शब्द है जो इंगित करता है कि कौन से हिस्से एक धारावाहिक संख्या सहन कर सकते हैं, इसलिए यह महत्वपूर्ण है (जहां तक ​​मैं आवश्यकताओं को समझता हूं)। –

+0

यदि ऐसा है, तो आप सही हैं। डोमेन विशेषज्ञता सब कुछ है। –

1

खैर ठीक है, आप ठीक उसी दीवार मैंने किया था जब मैं पहली बार :)

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

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

सू, मेरे अनुभव में (न कुछ लेखक जो OO के लिए मानचित्रण असली दुनिया उपमा भी आनंद मिलता है के अनुभव में: पी), TDD इस तरह जाना चाहिए:

  1. अपने तैनाती आरेख बनाएं, आवश्यकता विनिर्देश से (ओएफसी, कुछ नहीं पत्थर में सेट किया गया है - कभी)
  2. एक उपयोगकर्ता कहानी उठाओ लागू
  3. या अपने डोमेन के मॉडल को संशोधित इस कहानी
  4. शामिल करने के लिए करने के लिए या अपने वर्ग आरेख संशोधित इस कहानी शामिल करने के लिए (विभिन्न सहित डिजाइन कक्षाएं)
  5. परीक्षण-वैक्टर की पहचान करें।
  6. चरण 4
  7. में किए गए इंटरफ़ेस के आधार पर परीक्षण बनाएं परीक्षण (!) परीक्षण करें। यह एक बहुत ही महत्वपूर्ण कदम है ..
  8. कक्षाएं
  9. टेस्ट कक्षाएं
  10. जाओ लागू के साथ एक बियर है अपने सहकर्मियों :)
+5

यदि आप ऐसा कर रहे हैं तो आप टेस्ट ड्रावन विकास नहीं कर रहे हैं। आप परीक्षण लिख रहे हैं, लेकिन परीक्षण के मामलों से अपना डिज़ाइन नहीं ले रहे हैं। –

+2

हाँ, ठीक है, यह दर्शक की आंखों में है :) जिस तरह से मैं इसे देखता हूं, आप परीक्षण के कारणों से अपने 100% डिज़ाइन प्राप्त नहीं कर सकते हैं। कम से कम कुशलता से नहीं - imho।टेस्ट कार्यान्वयन के विवरण के लिए हैं, डिजाइन के लिए नहीं .. फिर, मेरे व्यक्तिगत दृष्टिकोण। – cwap

4

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

छोटे परीक्षण, मुझे लगता है कि आपको एक परीक्षण में पूरी तरह से सामान का परीक्षण नहीं करना चाहिए। जैसे Dपर इन पैरामीटर के साथ Method1(), Method2() और Method3() को कॉल करने के बाद राज्य 1, राज्य 2 और राज्य 3 में घटक डी.ए, बी और सी हैं। प्रत्येक परीक्षण को केवल एक चीज़ का परीक्षण करना चाहिए। आप अच्छे परीक्षणों के गुणों के लिए SO खोज सकते हैं।के रूप में एक बेक की किताब से सुझाव (AFAIR करने के लिए प्रयास करें:

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

+0

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

+0

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

+0

मैं वापस गया और बेक की किताब के पहले 40-50 पृष्ठों को पढ़ा और कुछ आखिरी पठन (कुछ महीने पहले) के बाद से कुछ और चीजें डूब गईं। दो चीजें जो मदद कर रही हैं वे हैं ए) आप टेस्ट पास करने के लिए पाप कर सकते हैं और बी) आप तुरंत एक बार हरे रंग में प्रतिक्रिया देते हैं। और हां, एसयूटी के संबंध में ध्यान केंद्रित करना और सोचना मेरी मदद कर रहा है, विशेष रूप से उन सभी संदर्भों के बारे में सोचना जो एसयूटी में मौजूद हो सकते हैं - यह मजबूत, कम भंगुर परीक्षणों की ओर अग्रसर है। – anonymous

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