TDD: मैं इसे सही कर रहा हूँ?


14

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

मै क्या कर रही हूँ:

  1. एक नई विधि के बारे में सोचो जिसकी मुझे जरूरत है।
  2. उस पद्धति के लिए एक परीक्षण बनाएं।
  3. असफल परीक्षण।
  4. विधि लिखिए।
  5. परीक्षा पास करना।
  6. रिफैक्टर विधि।
  7. दोहराएँ।

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

संपादित करें

इसके अलावा, यह कुछ ऐसा था जिसे मैं सोच रहा था। GUI बनाने जैसा कुछ करते समय, क्या TDD उस स्थिति में आवश्यक होगा? व्यक्तिगत रूप से, मैं यह नहीं सोच सकता कि मैं इसके लिए परीक्षण कैसे लिखूंगा।


5
आप पहले से ही अनुभवी पेशेवरों की तुलना में इसे बहुत बेहतर कर रहे हैं जो कहते हैं कि वे सब कुछ परीक्षण कर रहे हैं (लेकिन नहीं)।
यानिस

आप जो वर्णन करते हैं वह TDD की आत्मा नहीं है ।

1
आप ATDD या BDD में देखना चाहते हैं।
डायटबुद्ध

शायद उच्चतर शुरू करें - एक नए मॉड्यूल के बारे में सोचें जिसकी आपको आवश्यकता है।

जवाबों:


16

क्या आप एक कार्यप्रवाह के रूप में वर्णन कर रहे हैं मेरी राय में TDD की आत्मा नहीं है ।

अमेज़न पर केंट बेक की पुस्तक का सारांश कहता है:

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

प्रैक्टिकल टीडीडी

औपचारिक स्वचालित परीक्षण, विशेष रूप से यूनिट परीक्षण हर वर्ग की प्रत्येक विधि सिर्फ एक विरोधी पैटर्न के रूप में खराब है और कुछ भी परीक्षण नहीं कर रही है। होना शेष है। क्या आप हर setXXX/getXXXविधि के लिए इकाई परीक्षण लिख रहे हैं, वे तरीके भी हैं!

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

इस तरह सब कुछ की तरह, एक संतुलन है जिसे किसी और के द्वारा परिभाषित नहीं किया जा सकता है। किसी भी हठधर्मिता का तरीका शायद अधिक गलत है जो सही है।

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

आप कई व्यावसायिक दुकानों को खोजने के लिए बहुत मुश्किल हो रहे हैं जो इस तरह से काम करते हैं। यह सिर्फ पैसे के परीक्षण की चीजों को खर्च करने के लिए व्यापार की समझ में नहीं आता है जो कि एक साधारण धुएं के परीक्षण के बाद सभी व्यावहारिक उद्देश्यों के लिए कभी नहीं बदलेगा। .getXXX/.setXXXतरीकों के लिए औपचारिक स्वचालित इकाई परीक्षण लिखना इसका एक प्रमुख उदाहरण है, समय की पूरी बर्बादी।

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

- एद्जर W. Djikstra । (1988 में लिखा गया था, इसलिए यह अब 4.5 दशकों के करीब है।)

इस उत्तर को भी देखें ।


1
मुझे पता है कि मेरे बारे में बहुत चिंतित थे। मुझे लग रहा था कि मैं हर तरीके का परीक्षण नहीं कर रहा हूं जैसे कि मैं कर रहा था, लेकिन मुझे यकीन नहीं था। ऐसा लगता है कि मुझे अभी भी टीडीडी के बारे में कुछ और पढ़ने की आवश्यकता हो सकती है।
cgasser

@kevincline अधिकांश समय setXXX/getXXXकी बिल्कुल जरूरत नहीं है :)
चिप

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

13

तुम बहुत करीब हो। इसमें थोड़ा अलग तरीके से सोचने की कोशिश करें।

  1. एक नए व्यवहार के बारे में सोचो जिसकी मुझे जरूरत है।
  2. उस व्यवहार के लिए एक परीक्षा बनाएं।
  3. असफल परीक्षण।
  4. नया लिखें या मौजूदा पद्धति का विस्तार करें।
  5. परीक्षा पास करना।
  6. रिफैक्टर कोड।
  7. दोहराएँ।

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

इसके अलावा, चाचा बॉब के टीडीडी के तीन नियमों को याद रखें ।

  1. आपको किसी भी उत्पादन कोड को लिखने की अनुमति नहीं है जब तक कि यह एक असफल इकाई परीक्षण पास न हो।
  2. आपको एक इकाई परीक्षण लिखने की अनुमति नहीं है जो असफल होने के लिए पर्याप्त है; और संकलन विफलताओं विफलताओं हैं।
  3. आपको किसी भी अधिक उत्पादन कोड को लिखने की अनुमति नहीं है, एक असफल इकाई परीक्षा पास करने के लिए पर्याप्त है।

1
@Zexanima: आप एक साल के बाद हम में से ज्यादातर की तुलना में बेहतर कर रहे हैं। बस आपको अगले कदम की ओर इशारा करने की कोशिश की जा रही है।
पीडीआर

2
मुझे लगता है कि ये 3 नियम आपको लिंक करते हैं; के रूप में सुखद लग रहा है के रूप में वे ध्वनि कर सकते हैं, असाधारण हठधर्मी और अत्यधिक unrealistically सभी उत्पादन दुकानों के 99% में कठोर है कि किसी का भी सामना करेंगे।

1
@FrankShearar या इसे कट्टरपंथी अतिवादी और थोक अवहेलना के अव्यवहारिक धब्बा के रूप में देखा जा सकता है। मैंने उन दुकानों में काम किया है जिनके पास यह हठधर्मिता थी, उन्होंने हठधर्मिता को शाब्दिक रूप से लिया और इस बिंदु को याद किया; ऐसे परीक्षण लिखना जो किसी भी वास्तविक कोड का व्यावहारिक रूप से परीक्षण नहीं करते थे और अंत में परीक्षण करने के लिए मॉकिंग और डिपेंडेंसी इंजेक्शन फ्रेमवर्क का परीक्षण करने की क्षमता थी, जो कि सबसे महत्वपूर्ण था।

1
@pdr किसी चीज़ की आत्मा उस चीज़ के हठधर्मी औपचारिक रूप से विहितकरण के विपरीत है। यह एक बात है कि एक दर्शन और दूसरा इसे धर्म में बदल देना । TDD काले और सफेद हठधर्मी धार्मिक शब्दों के बारे में बातचीत नहीं करने की तुलना में अधिक बार है । 3 नियम है कि ध्वनि सिद्धांतवादी और प्रस्तुति में धार्मिक और जो सुना जाता है टेस्ट, टेस्ट, टेस्ट मंत्र, ओपी की तरह किसी को, वे उन्हें ले सचमुच और अच्छे से कि कारणों अधिक नुकसान। मैंने फ्रैंक को कहा कि ध्रुवीकरण वाले बयान अच्छे से ज्यादा नुकसान पहुंचा सकते हैं।

2
मेरा कहना था कि डॉगमैटिज़्म आँख बंद करके कुछ को सुसमाचार के रूप में स्वीकार करने से आता है । ध्रुवीकरण कथन लें, इसे आज़माएं, यह आपको आपके आराम क्षेत्र से बाहर कर देगा। यदि आप 3-बिंदु-सभी-या-कुछ चरम दृष्टिकोण की कोशिश नहीं करते हैं, तो आप टीडीडी में शामिल ट्रेडऑफ का मूल्यांकन नहीं कर सकते, क्योंकि आपके पास कोई डेटा नहीं होगा ।
फ्रैंक शीयर

5

अन्य की प्रतिक्रियाओं में जोड़ने के लिए कुछ चीजें:

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

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

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

  4. आपने GUI कोड के परीक्षण के बारे में पूछा। "विनम्र संवाद" और "MVVM" पैटर्न देखें। इन दोनों के पीछे विचार यह है कि आप "व्यू मॉडल" कक्षाओं का एक सेट बनाते हैं, जिसमें वास्तव में यूआई-विशिष्ट तर्क नहीं होता है। हालाँकि, इन वर्गों के पास सभी व्यावसायिक तर्क होंगे जो आमतौर पर आपके UI का हिस्सा होते हैं और ये कक्षाएं 100% परीक्षण योग्य होनी चाहिए। जो कुछ बचा है वह बहुत पतला UI शेल है और हां, आमतौर पर वह शेल बिना टेस्ट कवरेज के छोड़ दिया जाता है, लेकिन उस बिंदु पर इसका कोई तर्क नहीं होना चाहिए।

  5. यदि आपके पास मौजूदा कोड का एक बड़ा हिस्सा है, जैसा कि कुछ अन्य लोगों ने सुझाव दिया है, तो आपको यूनिट परीक्षणों को बिल्कुल हर जगह जोड़ना शुरू नहीं करना चाहिए। यह आपको हमेशा के लिए ले जाएगा और आपको 80% वर्गों के लिए यूनिट परीक्षणों को जोड़ने से लाभ नहीं मिलेगा जो कि स्थिर हैं और निकट भविष्य में नहीं बदलेंगे (या नहीं तो निकट भविष्य में भी नहीं)। हालांकि, नए काम के लिए, मुझे पता है कि सभी कोड के साथ TDD विकास का उपयोग करना बेहद फायदेमंद है। न केवल आप स्वचालित परीक्षणों के साथ एक सूट के साथ समाप्त होते हैं जब आप कर रहे हैं, लेकिन वास्तविक विकास में भारी लाभ हैं:

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

1

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

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


ठिक है। यही मैं नहीं कर रहा हूं। मैं आमतौर पर एक अलग स्थिति के बारे में सोचता हूं, मैं अपने तरीकों का परीक्षण कर सकता हूं एक तरीके से लाइन के बाद मैं अपने शुरुआती परीक्षण कर चुका हूं। मैं सिर्फ यह सुनिश्चित कर रहा था कि उन 'अतिरिक्त' परीक्षणों को बनाने लायक था, या अगर ऐसा करने से अधिक था।
cgasser

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

1

आम तौर पर आप इसे सही कर रहे हैं।

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

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


मैं गेटर्स के लिए टेस्ट लिख रहा था और उस टिप के लिए बहुत बहुत धन्यवाद। यह मुझे कुछ गैर-जरूरी काम बचा लेगा।
cassasser

"कुछ तरीकों को स्पष्ट रूप से परीक्षण करने की आवश्यकता नहीं है (यानी सरल गेटर्स और सेटर)" - आपने कभी भी एक गेट्टर और सेटर को कॉपी / पेस्ट नहीं किया है और इसके पीछे क्षेत्र का नाम बदलना भूल गए हैं? सरल कोड के बारे में बात यह है कि इसके लिए सरल परीक्षणों की आवश्यकता होती है - आप वास्तव में कितना समय बचा रहे हैं?
पीडीआर

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

गेट्टर और सेटर टेस्ट में लंबा समय नहीं लगता है, इसलिए मैं शायद उन्हें करना जारी रखूंगा। हालाँकि, मैं अपने किसी भी कोड को कभी भी कॉपी और पेस्ट नहीं करता, इसलिए मैं उस मुद्दे पर नहीं चलता।
cgasser

0

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

यदि आप कक्षा का परीक्षण करने के लिए अपने परीक्षणों को डिजाइन करते हैं, तो इसका उपयोग करने के लिए, तो आप कुछ लाभ प्राप्त करना शुरू करते हैं, खासकर जब आप ऐसे परीक्षण लिखना शुरू करते हैं जो प्रत्येक विधि की तुलना में थोड़ा अधिक व्यायाम करते हैं, खासकर जब आप उन लोगों की बातचीत का परीक्षण करना शुरू करते हैं तरीकों। मुझे लगता है कि आप इसे तरीकों के बजाय एक वर्ग के लिए परीक्षण लिखने के रूप में सोच सकते थे। किसी भी मामले में, आपको अभी भी 'स्वीकृति परीक्षण' लिखना होगा जो यह सुनिश्चित करने के लिए तरीकों के संयोजन का उपयोग करता है कि कोई विरोधाभास या संघर्ष नहीं है कि वे एक साथ कैसे उपयोग किए जाते हैं।

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

BDD v TDD के बारे में दाईं ओर कुछ अच्छे लिंक हैं। उनकी जाँच करो।


0

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

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


0

मेरा मानना ​​है कि आप ओवरइटिंग कर रहे हैं।

मैं कई वर्षों से टीडीडी का अभ्यास कर रहा हूं, और मेरे अनुभव में, जब टीडीडी को प्रभावी ढंग से किया जाता है, तो आपको दो मुख्य लाभ मिलते हैं:

  • तेजी से प्रतिक्रिया दें
  • पुन: सक्रिय करने में सक्षम करें

तेजी से प्रतिक्रिया दें

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

पुन: सक्रिय करने में सक्षम करें

यदि आपके पास एक अच्छा परीक्षण-सूट है, तो आप सुरक्षित रूप से रिफ्लेक्टर कर सकते हैं, क्योंकि आप सिस्टम को कैसे डिज़ाइन किया जाना चाहिए, इसमें नई अंतर्दृष्टि प्राप्त करते हैं।

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

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

यदि आप हालांकि, जैसा कि pdr के उत्तर में भी सुझाव दिया गया है , परीक्षण लिखते समय तरीकों के बजाय व्यवहार पर ध्यान केंद्रित करें , तो आपके पास ऐसे परीक्षण होंगे जो सिस्टम को रीफैक्टर करते समय बहुत कम परिवर्तनों की आवश्यकता होगी।

या जैसा कि इयान कूपर इस प्रस्तुति में कहते हैं (मैंने स्मृति से उद्धृत किया है, इसलिए इसे सही ढंग से उद्धृत नहीं किया जा सकता है):

एक नया परीक्षण लिखने का आपका कारण एक नया व्यवहार जोड़ना चाहिए, न कि एक नया वर्ग जोड़ना


-2

आपको हर सार्वजनिक पद्धति का परीक्षण करना चाहिए ।

यहां पकड़ यह है कि यदि आपके सार्वजनिक तरीके बहुत छोटे हैं तो आप शायद बहुत अधिक जानकारी उजागर कर रहे हैं। प्रत्येक संपत्ति को उजागर करने का सामान्य अभ्यास getXXX()वास्तव में इनकैप्सुलेशन को तोड़ता है।

यदि आपके सार्वजनिक तरीके वास्तव में वर्ग के व्यवहार हैं, तो आपको उनका परीक्षण करना चाहिए। यदि नहीं, तो वे अच्छे सार्वजनिक तरीके नहीं हैं।

EDIT: pdr का उत्तर मेरे मुकाबले बहुत अधिक पूर्ण है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.