मुझे समझ में नहीं आता है कि अगर मुझे परीक्षण शुरू करने के लिए एक डिजाइन की आवश्यकता है तो TDD मुझे एक अच्छा डिज़ाइन पाने में कैसे मदद करता है


50

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

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

वर्णन करने के लिए, इन 3 आवश्यकताओं की कल्पना करें:

  • एक कैटलॉग के लिए उत्पादों की एक सूची होनी चाहिए
  • कैटलॉग को याद रखना चाहिए कि उपयोगकर्ता कौन से उत्पाद देखता है
  • उपयोगकर्ताओं को किसी उत्पाद की खोज करने में सक्षम होना चाहिए

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

एक मौजूदा डिज़ाइन की आवश्यकता है, लेकिन इकाई-सेवाओं के बाहर सामान (यानी: एक उत्पाद है, इसलिए एक ProductService होना चाहिए) कहीं नहीं पाया जाता है (उदाहरण के लिए, दूसरी आवश्यकता के लिए मुझे कुछ अवधारणा की आवश्यकता है उपयोगकर्ता, लेकिन मैं याद दिलाने के लिए कार्यक्षमता कहां रखूंगा? और क्या ProductService की एक विशेषता या एक अलग SearchService खोज है? मुझे कैसे पता चलेगा कि मुझे कौन सा चुनना चाहिए?)

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

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


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

3
@gnat: यह इस बात की जांच है कि TDD पुस्तकें डिज़ाइन प्रक्रिया को स्पष्ट क्यों नहीं करती हैं।
रॉबर्ट हार्वे

4
@gnat: यह आपका संपादन था, मेरा नहीं। :) प्रश्न और शरीर के शीर्षक में मेरा परिवर्तन देखें।
रॉबर्ट हार्वे

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

3
तो यह वास्तव में परीक्षण के बारे में नहीं है, यह डिजाइन के बारे में है। केवल यह वास्तव में आपको डिजाइन के साथ मदद नहीं कर रहा है, इसलिए आपको डिजाइन को मान्य करने में मदद करता है। लेकिन ऐसा नहीं है! @ # $ आईएनजी परीक्षण?
एरिक रेपेन

जवाबों:


17

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

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


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


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


रॉबर्ट हार्वे ने टिप्पणी में यह जोड़ा है जो जवाब में बताते हुए लायक है:

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


31
@MichaelStum: दुर्भाग्य से मुझे लगता है कि यह TDD के बारे में एक आम गलत धारणा है: आप सिर्फ यूनिट टेस्ट लिखकर और उन्हें पास कर किसी सॉफ्टवेयर आर्किटेक्चर को विकसित नहीं कर सकते। इकाई परीक्षण लिखना डिज़ाइन को प्रभावित करता है, लेकिन यह डिज़ाइन नहीं बनाता है। आपको वह करना होगा।
रॉबर्ट हार्वे

4
@ रोबर्टहवे, जिमीहॉफ: अगर मैं आपकी टिप्पणियों को 100 बार वोट कर सकता हूं, तो मैं करूंगा!
डॉक ब्राउन

9
@ रोबर्ट हार्वे: मुझे खुशी है कि आपने इस आम ग़लतफ़हमी के बारे में लिखा है: मुझे अक्सर ऐसा सुनने को मिलता है कि किसी को बस बैठकर सभी तरह के यूनिट टेस्ट लिखने पड़ते हैं और एक डिज़ाइन अनायास ही "उभर कर" आ जाता है। और अगर आपका डिज़ाइन खराब है, तो इसका कारण यह है कि आपने पर्याप्त इकाई परीक्षण नहीं लिखे हैं। मैं आपसे सहमत हूं कि परीक्षण आपके डिजाइन के लिए आवश्यकताओं को निर्दिष्ट करने और सत्यापित करने के लिए एक उपकरण है, लेकिन "आपको खुद को डिजाइन करना होगा"। मैं पूरी तरह सहमत हूँ।
जियोर्जियो

4
@Giorgo, RobertHarvey: +1000 से RobertHarvey मुझसे भी। दुर्भाग्य से, यह गलत धारणा आम है कि कुछ "विशेषज्ञ" टीडीडी / एजाइल चिकित्सक इसे सच मानते हैं। उदाहरण के लिए, वे दिखावा करते हैं कि आप किसी भी तरह के डोमेन ज्ञान या विश्लेषण के बिना TDD से बाहर एक सुडोकू सॉल्वर को "विकसित" कर सकते हैं । मुझे आश्चर्य है कि अगर रॉन जेफ्रीस ने कभी भी टीडीडी की सीमाओं पर एक अनुवर्ती प्रकाशित किया या समझाया कि उन्होंने अचानक किसी भी निष्कर्ष या सबक के बिना अपने प्रयोग को क्यों रोक दिया।
एंड्रेस एफ

3
@Andres F: मुझे सुडोकू के बारे में कहानी पता है, और मुझे लगता है कि यह बहुत दिलचस्प है। मुझे लगता है कि कुछ डेवलपर्स यह सोचने की गलती करते हैं कि एक उपकरण (जैसे टीडीडी या एससीआरयूएम) डोमेन ज्ञान और अपने स्वयं के प्रयासों को बदल सकता है, और उम्मीद करता है कि यांत्रिक रूप से एक विशेष विधि को लागू करने से अच्छा सॉफ्टवेयर जादुई रूप से "उभर" जाएगा। वे अक्सर ऐसे लोग होते हैं जो विश्लेषण और डिजाइन में बहुत अधिक समय बिताना पसंद नहीं करते हैं और सीधे कुछ को कोड करना पसंद करते हैं। उनके लिए, एक विशेष कार्यप्रणाली का पालन करना उचित डिजाइन न करने के लिए एक ऐलिबी है। लेकिन यह आईएमएचओ टीडीडी का दुरुपयोग है।
जियोर्जियो

8

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

इसे यह कैसे करना है?

सबसे पहले, यह मुझे कुछ क्लाइंट कोड की सेवा के रूप में हर वर्ग के बारे में सोचने के लिए प्रोत्साहित करता है। बेहतर कोड यह सोचने से आता है कि कॉलिंग कोड एपीआई का उपयोग कैसे करना चाहता है, इस बारे में चिंता करने के बजाय कि कोड को कैसे दिखना चाहिए।

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

यह वास्तव में इतना आसान है। यह एक जादू डिजाइन उपकरण नहीं है।


6

मैं अपने सिर को टीडीडी के चारों ओर लपेटने की कोशिश कर रहा हूं ... वर्णन करने के लिए, इन 3 आवश्यकताओं की कल्पना करें:

  • एक कैटलॉग के लिए उत्पादों की एक सूची होनी चाहिए
  • कैटलॉग को याद रखना चाहिए कि उपयोगकर्ता कौन से उत्पाद देखता है

इन आवश्यकताओं को मानवीय दृष्टि से बहाल किया जाना चाहिए। कौन जानना चाहता है कि उपयोगकर्ता पहले कौन से उत्पाद देखता है? उपभोक्ता? एक विक्रेता?

  • उपयोगकर्ताओं को किसी उत्पाद की खोज करने में सक्षम होना चाहिए

कैसे? नाम से? ब्रांड द्वारा? परीक्षण-संचालित विकास में पहला कदम एक परीक्षा को परिभाषित करना है, उदाहरण के लिए:

browse to http://ourcompany.com
enter "cookie" in the product search box
page should show "chocolate-chip cookies" and "oatmeal cookies"

>

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

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

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


ठीक है, नहीं ProductServiceतो। लेकिन टीडीडी ने आपको कैसे बताया कि आपको एक डेटाबेस और एक ORM की आवश्यकता थी?
रॉबर्ट हार्वे

4
@ रॉबर्ट: यह नहीं था। यह एक डिजाइन निर्णय है, जो आवश्यकता को पूरा करने के सबसे प्रभावी तरीके के मेरे निर्णय पर आधारित है। लेकिन फैसला बदल सकता था।
केविन क्लाइन

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

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

3

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

कुछ उदाहरण जहां मैंने अतीत में चलाए हैं:

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

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

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

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

यदि आप TDD कर रहे हैं और यह आपके लिए काम कर रहा है, तो आपके लिए अच्छा है, लेकिन बहुत सारी चीजें हैं (पूरी नौकरी, या किसी परियोजना के चरण) वहां से बाहर हैं जहां यह सिर्फ मूल्य नहीं जोड़ता है।

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


1

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

FYI करें - दो पुस्तकें मैं इस विषय पर सलाह देता हूं जो मूर्त और यथार्थवादी उदाहरण देते हैं:

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

परीक्षण-संचालित विकास एक व्यावहारिक मार्गदर्शिका - एक पूर्ण, यद्यपि छोटा, ऐप विकसित करने के माध्यम से एक धीमी और चरण-दर-चरण चलना।


0

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

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

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


1
मैं सहमत हूं कि यह एक मान्य वर्कफ़्लो है, लेकिन यह वास्तव में यह नहीं समझाता है कि इस तरह के वर्कफ़्लो से उच्च-स्तरीय आर्किटेक्चर कैसे उभर सकता है।
रॉबर्ट हार्वे

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

0

प्रश्न में यह कहा गया है:

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

वे इस निष्कर्ष पर पहुंचे कि वे इस उत्पाद का परीक्षण कैसे करने जा रहे हैं। "यह किस प्रकार का उत्पाद है?" "ठीक है, हम एक सेवा बना सकते हैं"। "ठीक है, चलो ऐसी सेवा के लिए एक परीक्षा लिखें"


0

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

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

फिर, जब आपको उन संस्थाओं को प्रबंधित करने के तरीकों के बारे में उपलब्ध विकल्पों की एक अच्छी भावना मिलती है, तो आप आपको TDD दृष्टिकोण दे सकते हैं।


0

क्या TDD मुझे पहले स्थान पर अपना डिज़ाइन खोजने का इरादा नहीं है?

नहीं।

आप किसी ऐसी चीज़ का परीक्षण कैसे कर सकते हैं जिसे आपने पहले नहीं बनाया है?

वर्णन करने के लिए, इन 3 आवश्यकताओं की कल्पना करें:

  • एक कैटलॉग के लिए उत्पादों की एक सूची होनी चाहिए
  • कैटलॉग को याद रखना चाहिए कि उपयोगकर्ता कौन से उत्पाद देखता है
  • उपयोगकर्ताओं को किसी उत्पाद की खोज करने में सक्षम होना चाहिए

ये आवश्यकताएं नहीं हैं, ये डेटा की परिभाषाएं हैं। मुझे नहीं पता कि आपके सॉफ़्टवेयर का व्यवसाय क्या है, लेकिन यह संभावना नहीं है कि विश्लेषक उस तरह से बोलते हैं।

आपको यह जानना होगा कि आपके सिस्टम के आक्रमणकारी क्या हैं।

एक आवश्यकता कुछ इस तरह होगी:

  • एक ग्राहक एक निश्चित मात्रा में उत्पाद ऑर्डर कर सकता है, अगर स्टॉक में इस उत्पाद के लिए पर्याप्त है।

इसलिए यदि यह एकमात्र आवश्यकता है, तो आपके पास एक वर्ग हो सकता है जैसे:

public class Product {

  private int quantity;

  public Product(int initialQuantity) {
    this.quantity = initialQuantity;
  }

  public void order(int quantity) {
    // To be implemented.
  }

}

फिर टीडीडी का उपयोग करके, आप ऑर्डर () विधि को लागू करने से पहले एक परीक्षण केस लिखेंगे।

public void ProductTest() {

    public void testCorrectOrder() {

        Product p = new Product(10);
        p.order(3);
        p.order(4);

    }

    @Expect(ProductOutOfStockException)
    public void testIncorrectOrder() {

        Product p = new Product(10);
        p.order(7);
        p.order(4);

    }

}

तो दूसरा परीक्षण विफल हो जाएगा, फिर आप आदेश () विधि को अपनी पसंद के अनुसार लागू कर सकते हैं।


0

आप काफी सही हैं TDD एक दिए गए डिजाइन का एक अच्छा कार्यान्वयन में परिणाम होगा । यह आपकी डिज़ाइन प्रक्रिया में मदद नहीं करेगा।


हालांकि यह आपको वर्किंग कोड को तोड़े बिना डिजाइन को बेहतर बनाने के लिए सेफ्टी नेट देता है। यह ज्यादातर लोगों को छोड़ भागा है।
एड्रियन श्नाइडर

-3

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

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