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