2010-08-08 8 views
7

तो मैं टीडीडी में उपयोग कर रहा हूं, लेकिन मुझे एक अप्रत्याशित समस्या आई है: मैं वास्तव में 100% कोड कवरेज से थक गया हूं। परीक्षण कोड से खुद लिखने के लिए और अधिक कठिन हो रहे हैं, और मुझे यकीन नहीं है कि मैं इसे सही कर रहा हूं। मेरा सवाल है: आपको किस प्रकार की चीजों का परीक्षण करना चाहिए, और किस तरह की चीजें अधिक हो गई हैं?टीडीडी/यूनिट परीक्षण थकान से निपटना

उदाहरण के लिए, मेरे पास निम्नानुसार एक परीक्षण है, और मुझे यकीन नहीं है कि यह बिल्कुल उपयोगी है या नहीं। मुझे क्या करना है ताकि मैं अभी भी टीडीडी का पालन करूँ लेकिन परीक्षण लिखने से थक गया न हो?

describe 'PluginClass' 

    describe '.init(id, type, channels, version, additionalInfo, functionSource, isStub)' 

     it 'should return a Plugin object with correct fields' 

      // Create test sets 
      var testSets = new TestSets() 
      var pluginData = { 
       'id'    : null, 
       'type'    : null, 
       'channels'   : null, 
       'version'   : null, 
       'additionalInfo' : null, 
       'functionSource' : null, 
       'isStub'   : true 
      } 
      testSets.addSet({ 'pluginData' : pluginData }) 
      var pluginData = { 
       'id'    : "testPlugin1", 
       'type'    : "scanner", 
       'channels'   : ['channelA', 'channelB'], 
       'version'   : "1.0", 
       'additionalInfo' : {'test' : "testing"}, 
       'functionSource' : "function() {alert('hi')}", 
       'isStub'   : false 
      } 
      testSets.addSet({ 'pluginData' : pluginData }) 

      for (var t = 0; t < testSets.getSets().length; t ++) { 
       var aTestSet = testSets.getSet(t) 

       var plugin = new Plugin().init(aTestSet.pluginData.id, 
               aTestSet.pluginData.type, 
               aTestSet.pluginData.channels, 
               aTestSet.pluginData.version, 
               aTestSet.pluginData.additionalInfo, 
               aTestSet.pluginData.functionSource, 
               aTestSet.pluginData.isStub ) 

       plugin.getID().should.eql aTestSet.pluginData.id 
       plugin.getType().should.eql aTestSet.pluginData.type 
       plugin.getChannels().should.eql aTestSet.pluginData.channels 
       plugin.getVersion().should.eql aTestSet.pluginData.version 
       plugin.getAdditionalInfo().should.eql aTestSet.pluginData.additionalInfo 
       eval("fn = " + aTestSet.pluginData.functionSource) 
       JSON.stringify(plugin.getFunction()).should.eql JSON.stringify(fn) 
       plugin.getIsStub().should.eql aTestSet.pluginData.isStub 
      } 

     end 

    end 

end 
+0

आईएमओ, यह एक स्वीकृति परीक्षण है। – Gutzofter

उत्तर

7

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

टेस्ट-संचालित विकास का मतलब है: आपको बच्चे के चरणों में जाना चाहिए, जहां प्रत्येक चरण एक अलग परीक्षण है, केवल एक चीज का दावा करता है, और इसमें कोई तर्क नहीं है (यानी for, if/else या इसी तरह ...)। तो उपर्युक्त कोड के परिणामस्वरूप लगभग 4-6 अलग-अलग परीक्षण विधियां होंगी, जिन्हें आप एक-एक करके कार्यान्वित करेंगे। सबसे पहले सही संपत्ति initalization (आवश्यकतानुसार विभिन्न मूल्यों के साथ) पर जोर दें, फिर सुनिश्चित करें कि विधियों की अपेक्षा की जाती है, और इसी तरह ...

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

योग में: यह सब कुछ के लिए परीक्षण करने के लिए अधिक नहीं है (100% कवरेज), लेकिन यह निश्चित रूप से आपके उदाहरण में परीक्षण करने में एक समस्या है।

मैं तुम्हें अपनी TDD/इकाई परीक्षण अभ्यास समीक्षा करने की अनुशंसा, The Art Of Unit Testing किताब एक अच्छा संसाधन हो सकती है ...

HTH!
थॉमस

+0

+1 * यूनिट परीक्षण की कला * की सिफारिश करने के लिए +1 - यह एक अच्छी किताब है जो वास्तव में अच्छी सलाह देती है। – Bevan

1

यूनिट परीक्षण का लक्ष्य कोड के उन हिस्सों का परीक्षण करना चाहिए जिनमें बग शामिल होने की संभावना है। 100% परीक्षण कवरेज हासिल करना एक लक्ष्य नहीं होना चाहिए, और AFAIK, टीडीडी इसे लक्ष्य के रूप में नहीं बुलाता है।

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

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

+0

"100% परीक्षण कवरेज ... टीडीडी इसे लक्ष्य के रूप में नहीं बुलाता है"। यह वास्तव में करता है, अपने धार्मिक रूप में टीडीडी लाइव कोड की किसी भी पंक्ति से पहले लिखित परीक्षा की मांग करता है। अन्यथा सहमत हैं। – KolA

+0

इसे पढ़ें: http://agiledata.org/essays/tdd.html#Misconceptions –

3

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

तो इसके लिए जाएं।

+1

बहुत सच है। आम तौर पर यह एक संकेत है कि कहीं कुछ गड़बड़ है। – obelix

0

ऐसा लगता है कि आप साधारण सदस्य काम के साथ

  • परीक्षण कंस्ट्रक्टर्स कर रहे हैं। यह तब तक अधिक है जब तक कि कन्स्ट्रक्टर में कुछ गैर-तुच्छ तर्क नहीं होता है। इसके बजाय कुछ अन्य परीक्षणों के हिस्से के रूप में परीक्षण करने के लिए इस पर भरोसा करें जहां सदस्यों का उपयोग किया जाएगा।
  • 2 मूल्य वस्तुओं के बीच समानता की तुलना। बराबर विधि को ओवरराइड करके प्लगइन प्रकार/कक्षा पर समानता जांच को परिभाषित/परिभाषित करें। इसलिए plugin.should.eql expected_plugin एकमात्र assert
  • जटिल परीक्षण डेटा बनाने के लिए सहायक वस्तुओं का उपयोग करने पर भी विचार करना चाहिए।
1

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

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

0

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

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

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

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