TDD करते समय एक बार में सभी परीक्षण क्यों नहीं लिखे?

Question

रेड - ग्रीन - टीडीडी के लिए रिफ्लेक्टर चक्र अच्छी तरह से स्थापित और स्वीकृत है। हम एक असफल इकाई परीक्षण लिखते हैं और इसे यथासंभव सरल बनाते हैं। एक वर्ग के लिए कई असफल इकाई परीक्षण लिखने पर इस दृष्टिकोण के लिए क्या लाभ हैं और उन सभी को एक बार में पास करें।

टेस्ट सूट अभी भी आपको गलत कोड लिखने या रीफैक्टरिंग चरण में गलतियां करने से बचाता है, तो नुकसान क्या है? कभी-कभी एक क्लास (या मॉड्यूल) के लिए सभी परीक्षणों को पहले 'ब्रेन डंप' के रूप में लिखना आसान होता है, ताकि एक ही बार में सभी अपेक्षित व्यवहार को जल्दी से लिख सकें।

Comments

वह करें जो आपके लिए सबसे अच्छा काम करे (कुछ प्रयोग के बाद)। हठधर्मिता का अनुसरण करना कभी भी अच्छी बात नहीं है।

— माइकल Borgwardt

मुझे लगता है कि एक बार में अपने सभी परीक्षण लिखने की तरह एक बार में अपने सभी परीक्षण कोड लिखने की हिम्मत ।

— माइकल हरेन

@MichaelHaren एक वर्ग (या कार्यात्मक मॉड्यूल) के लिए सभी परीक्षण, भ्रम की स्थिति के लिए खेद है

— RichK

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

— सैम गोल्डबर्ग

अच्छी तरह से मुझे नहीं पता कि किसी ने इसका उल्लेख क्यों नहीं किया, लेकिन आप एक बार में सभी परीक्षण नहीं लिख सकते । हाथ से पहले सभी परीक्षणों को लिखना BDUF करने जैसा ही है । और इतिहास ने हमें BDUF के बारे में क्या सिखाया है? यह लगभग कभी काम नहीं करता है।

— सांगो

Answer 1

टेस्ट संचालित डिजाइन आपके एपीआई के अधिकार के बारे में है , कोड के बारे में नहीं।

पहले सबसे सरल असफल परीक्षण लिखने का लाभ यह है कि आपको अपना एपीआई मिलता है (जो अनिवार्य रूप से आप मक्खी पर डिजाइन कर रहे हैं) जितना संभव हो उतना सरल। सामने सामने।

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

Comments

बहुत बढ़िया अंक! हम कभी-कभी कोड के परीक्षण में इतने डूब जाते हैं कि हम कभी-कभी अनदेखा कर देते हैं कि आपका पहला परीक्षण लिखने से पहले एपीआई और डोमेन मॉडल कितना महत्वपूर्ण हो सकता है।

— maple_shaft

टेस्ट प्रेरित विकास के इरादे को संबोधित करने के लिए +1 ।

— यहोशू ड्रेक

Answer 2

जब आप एक परीक्षा लिखते हैं , तो आप एक बात पर ध्यान केंद्रित करते हैं ।
कई परीक्षणों के साथ आपने कई कार्यों पर अपना ध्यान केंद्रित किया है, इसलिए यह एक अच्छा विचार नहीं है।

Comments

कौन इसको कम करेगा ?!

— CaffGeek

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

— जोशुआ ड्रेक

मैंने इसे कम नहीं किया लेकिन; मैंने इसके बारे में सोचा था। यह एक जटिल प्रश्न का उत्तर है।

— मार्क वेस्टन

एक समय में एक चीज़ पर ध्यान केंद्रित करने के लिए +1, मल्टीटास्क की हमारी क्षमता खत्म हो गई है।

— cctan

यह सबसे सरल उत्तर है जो संभवतः काम कर सकता है।

— डीएनए

Answer 3

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

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

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

Comments

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

— maple_shaft

Answer 4

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

Comments

अधिकांश व्यावसायिक और उद्यम अनुप्रयोग तकनीकी रूप से प्रकृति में तुच्छ होते हैं और देखते हैं कि अधिकांश अनुप्रयोग व्यवसाय और उद्यम कैसे हैं, अधिकांश अनुप्रयोग इस प्रकार प्रकृति द्वारा भी तुच्छ हैं।

— मेपल_शाफ्ट

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

— जेएफओ

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

— maple_shaft

अगर मैं सही ढंग से समझूं, तो यह जवाब सवाल से भीख मांग रहा है।

— कोनराड रुडोल्फ

@maple_shaft मुझे लगता है कि जेफ ओ को उनकी टिप्पणी के साथ क्या मिल रहा था, नहीं?

— ZweiBlumen

Answer 5

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

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

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

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

Comments

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

— मार्क वेस्टन

Answer 6

TDD के पीछे का विचार तेजी से पुनरावृत्तियों है।

यदि आपके पास बड़ी संख्या में परीक्षण हैं, जो आपको अपने कोड को लिखने से पहले करना है तो यह आपके कोड को पुनरावृत्ति करना मुश्किल है।

आसान कोड रिफैक्टिंग के बिना आप टीडीडी के बहुत सारे लाभ खो देते हैं।

Answer 7

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

यदि आपको जानकारी के मस्तिष्क डंप की आवश्यकता है, तो आपके पास बहुत सारे विकल्प हैं:

• व्हाइटबोर्ड
• प्रयोक्ता कहानियां
• टिप्पणियाँ
• अच्छा राजभाषा 'कलम और कागज

ध्यान दें कि इस सूची में कहीं भी संकलक नहीं है। :-)

Answer 8

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

प्रत्येक इकाई परीक्षण के बारे में सोचें जिसे आप एक वैज्ञानिक नोटबुक में एक सिद्धांत के रूप में लिखते हैं। जैसा कि आप नोटबुक भरते हैं आप अपने सिद्धांतों को साबित करते हैं और नए रूप बनाते हैं। कभी-कभी एक नए सिद्धांत को साबित करना पिछले सिद्धांत को खारिज कर देता है, इसलिए आपको इसे ठीक करना होगा। एक बार में 20 कहने का प्रयास करने के बजाय एक सिद्धांत को एक बार में सिद्ध करना आसान है।

Comments

टीडीडी आपको मानता है कि आपके कोड को लिखने से पहले आपका कोड कैसा दिखेगा, बस छोटे टुकड़ों में।

— माइकल शॉ

Answer 9

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

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

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

Answer 10

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

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

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

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

Answer 11

मैंने एक ऐसी परियोजना पर काम किया है जहाँ डेवलपर्स (असफल) परीक्षण लिखने वाले डेवलपर्स को पास करने के लिए आवश्यक कोड को लागू करने वाले डेवलपर्स से अलग थे और मुझे यह वास्तव में प्रभावी लगा।

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

Answer 12

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

Answer 13

Red-Green-Refactor चक्र एक चेकलिस्ट है जो डेवलपर्स के लिए TDD में नया है। मैं कहूंगा कि इस चेकलिस्ट का अनुसरण करना एक अच्छा विचार है, जब तक आप यह नहीं जानते कि इसे कब फॉलो करना है और कब आप इसे तोड़ सकते हैं (यानी, जब तक कि आपको स्टैकओवरफ्लो पर यह सवाल नहीं पूछना है :)

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

Answer 14

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

सामान्य दृष्टिकोण तो धीरे-धीरे अधिक से अधिक स्वीकृति परीक्षणों को कवर करना है, जो कि परियोजना प्रबंधक और ग्राहक को दिखाई देने वाली प्रगति है।

आपके पास आमतौर पर यह परीक्षण निर्दिष्ट और निष्पादित किया जाता है जैसे कि बीडीडी ढांचे में ककड़ी, फिटने या कुछ ऐसे।

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

रेड-ग्रीन-रिफ्लेक्टर अनुशासन के बहुत सारे लाभ हैं, और केवल आप उल्टा उन्हें टाइप करके उम्मीद कर सकते हैं कि उन्हें भी तोड़ना है।

Answer 15

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

सभी परीक्षण: विश्लेषण और डिजाइनिंग आपको समस्या के दायरे के बारे में अधिक बता सकते हैं। चौड़ाई-पहले डिज़ाइन के बारे में सोचें। आप अधिक कोणों से समस्या का विश्लेषण करते हैं और अनुभव से इनपुट जोड़ते हैं। यह स्वाभाविक रूप से कठिन है, लेकिन कम लाभकारी परिणाम प्राप्त कर सकता है - यदि आप 'बस इसे पर्याप्त' करते हैं। ओवर-विश्लेषण करना आसान है और अभी तक पूरी तरह से निशान को याद रखें!

मुझे यह मुश्किल लगता है कि आम तौर पर एक या दूसरे को पसंद करने की सलाह देते हैं, क्योंकि कारक कई हैं: अनुभव (विशेष रूप से एक ही समस्या के साथ), डोमेन ज्ञान और कौशल, रिफैक्टिंग के लिए कोड की मित्रता, समस्या की जटिलता ...

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

Answer 16

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

describe "Your API" do

  it "should foo" do
    pending "braindump from 4/2"
  end

  it "should bar" do
    pending "braindump from 4/2"
  end

  it "should not biz" do
    pending "braindump from 4/2"
  end

end