टीडीडी

Question

पढ़ाने के दौरान प्रदान करने के लिए सबसे महत्वपूर्ण बात यह है कि मैं दिलचस्पी रखने वाले लोगों को टीडीडी के अभ्यास को पढ़ाने में मदद करने के लिए पेशेवरों के एक समूह के साथ सहयोग कर रहा हूं, लेकिन कोई अनुभव नहीं है (नौसिखिया)।

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

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

Answer 1

It's about design। यह परीक्षण के बारे में नहीं है।

Answer 2

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

लाल - हरा - रिएक्टर -> बस इसे करें।

Answer 3

मेरे अनुभव में, टीडीडी का उपयोग करके मुझे और मेरी टीम को बिना किसी चिंता के हमारे कोड को दोबारा बेदखल करने की अनुमति मिलती है कि यह कहीं अप्रत्याशित कुछ तोड़ देगा।

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

Answer 4

सिर्फ इसलिए कि आपके परीक्षण पास होने का मतलब यह नहीं है कि कोड सही है।

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

Answer 5

मेरा सुझाव है, "धैर्य रखें।" यह शुरुआत में अजीब लगता है। मेरे लिए, यह प्राकृतिक महसूस करने से पहले शायद तीन परियोजनाएं थीं।

Answer 6

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

Answer 7

बच्चे के चरणों में आगे बढ़ें।

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

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

Answer 8

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

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

Answer 9

मैं क्या Jon said in his answer से सहमत हैं, लेकिन मुझे लगता है एक महत्वपूर्ण परिणाम है कि testability "अच्छा डिजाइन" यह तय नहीं होता है, लेकिन केवल एक संकेतक लक्ष्य पर में है कि अपने डिजाइन है।

Answer 10

मुझे नहीं पता कि यह एक सबसे महत्वपूर्ण बात के रूप में गिना जाएगा - लेकिन यह कुछ ऐसा था जो मुझे "पाने" के लिए कुछ समय लगा जब मैं पहली बार टीडीडी का उपयोग कर खोज कर रहा था।

परीक्षा लिखने से पहले अपने सिर में कोड न लिखें।

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

मैं इस मैं वास्तव में TDD कर नहीं किया गया था जब कर रहा था - के बाद से मैं कोड पहले लिख रहा था (भले ही कोड केवल मेरे सिर :-)

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

Answer 11

टीडीडी, मेरे दिमाग में, लय (लाल, हरा, रिफैक्टर) के बारे में है। लय प्राप्त करना आपको "इसे प्राप्त नहीं करने" के "कूबड़" पर ले जाता है। और यदि आपको लय नहीं मिलता है तो आप टीडीडी के साथ बहुत लंबे समय तक नहीं रहेंगे। लय का सार बच्चा कदम है, जिसका पहले ही उल्लेख किया जा चुका है। जितना संभव हो उतना छोटा कोड लिखें, और निर्दयतापूर्वक refactor।

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

Answer 12

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

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

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