टीडीडी का उपयोग कैसे करें जब फिक्स में टेस्ट के हस्ताक्षर के तहत विधि को बदलना शामिल हो?

Question

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

string RemoveTokenFromString (string delimited, string token) 

के रूप में, इस विधि एक tokendelimited से की सभी आवृत्तियों दूर करता है और उसके एवज में स्ट्रिंग रिटर्न:

निम्नलिखित विधि हस्ताक्षर पर विचार करें।

मुझे बाद में पता चलता है कि इस विधि में एक बग है (उदाहरण के लिए स्ट्रिंग से गलत बिट्स को हटाया जा रहा है)। तो मैं परिदृश्य का वर्णन करने वाला एक परीक्षण केस लिखता हूं जहां बग होता है और यह सुनिश्चित करता है कि परीक्षण विफल हो जाए।

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

तब मैं क्या करूँ? अगर मैं बग ठीक करता हूं, तो यह मुझे यूनिट टेस्ट बदलने के लिए मजबूर करता है - क्या यह 'सही' टीडीडी पद्धति होगी?

Answer 1

आपके परीक्षणों पर बमबारी करने में बिल्कुल कुछ भी गलत नहीं है, जब आप पाते हैं कि इकाई का इच्छित व्यवहार बदलता है।

//Up front 
[Test] 
public void should_remove_correct_token_from_string() 
{ 
    var text = "do.it.correctly.."; 
    var expected = "doitcorrectly"; 
    Assert.AreEqual(StaticClass.RemoveTokenFromString(text, "."), expected); 
} 

//After finding that it doesn't do the right thing 
//Delete the old test and *design* a new function that 
//Does what you want through a new test 
//Remember TDD is about design, not testing! 
[Test] 
public void should_remove_correct_token_from_string() 
{ 
    var text = "do.it.correctly.."; 
    var expected = "doitcorrectly"; 
    Assert.AreEqual(
     StaticClass.RemoveTokenFromString(
      text, 
      ".", 
      System.Text.Encoding.UTF8), expected); 
} 

//This will force you to add a new parameter to your function 
//Obviously now, there are edge cases to deal with your new parameter etc. 
//So more test are required to further design your new function 

Answer 2

लाल, हरा, रिएक्टर।

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

Answer 3

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

Answer 4

एक रिफैक्टरिंग कि यहाँ मदद कर सकता है Add Parameter कहा जाता है।

यदि आपकी भाषा method overloading का समर्थन करती है, तो आप पहले नए पैरामीटर के साथ नया फ़ंक्शन बना सकते हैं, मौजूदा फ़ंक्शन के शरीर की प्रतिलिपि बना सकते हैं और अपनी समस्या को ठीक कर सकते हैं।

फिर जब समस्या ठीक हो जाती है, तो आप नई विधि को कॉल करने के लिए सभी परीक्षणों को एक-एक करके संशोधित कर सकते हैं। अंत में आप पुरानी विधि को हटा सकते हैं।

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

यह थोड़ा प्रक्रिया-व्यापक है, लेकिन मुझे लगता है कि यह लाल-हरे-रिएक्टर का पालन करने के लिए टीडीडी तरीका है।

पैरामीटर के लिए डिफ़ॉल्ट मान भी उपलब्ध होने पर मदद कर सकता है।

Answer 5

इसे आसान रखें।

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

लाल, हरा, रिफैक्टर भी आपके यूनिट परीक्षणों पर लागू होता है, न केवल आपके द्वारा परीक्षण किए जा रहे कोड।

Answer 6

मैं कहूंगा कि 'सही'/'सही' तरीके से परेशान न हो ... जो भी आपको समाधान के करीब ले जाने में मदद करता है।

आप पाते हैं कि आप एक अतिरिक्त पैरामीटर में लेने के लिए की जरूरत है,

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

केवल मामलों में जहां एक नया पैरामीटर जोड़ने संकलन त्रुटियों के zillions में परिणाम होगा, मैं करने की सलाह देते हैं - यह बच्चे चरणों में ले जा रहा है ... आप न जानने क्या तुम सच में नहीं था 'से पहले पूरे स्रोत आधार अपडेट करना चाहते हैं टी को तीसरे परम की आवश्यकता नहीं है या आपको चौथे की जरूरत है .. समय गुम हो गया। इसलिए सभी संदर्भों को अपडेट करने से पहले 'काम करने' विधि का नया संस्करण प्राप्त करें। (फिलिप यहाँ कहते हैं)

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

Answer 7

आप टीडीडी में सबसे खतरनाक जाल में गिर गए हैं: आपको लगता है कि टीडीडी परीक्षण के बारे में है, लेकिन ऐसा नहीं है। हालांकि, उस जाल में गिरना आसान है, क्योंकि टीडीडी में सभी शब्दावली परीक्षण के बारे में है। यही कारण है कि बीडीडी का आविष्कार किया गया था: यह अनिवार्य रूप से टीडीडी है, लेकिन भ्रमित शब्दावली के बिना।

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

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