टीडीडी बनाम उत्पादकता

Question

अपनी वर्तमान परियोजना में (C ++ में एक गेम), मैंने फैसला किया कि मैं विकास के दौरान टेस्ट ड्रिवेन डेवलपमेंट 100% का उपयोग करूंगा।

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

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

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

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

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

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

Comments

@ नायरौ: आप हमेशा "परियोजना समाप्त होने" की कोशिश कर सकते थे! अब एक शाखा बनाओ। बस वहां कोड लिखें। लेकिन आप जो करते हैं उसे सीमित करें, या तो समय या खेल संस्थाओं की संख्या से और देखें कि क्या आप तेजी से चले गए हैं। फिर आप उस शाखा को अनदेखा कर सकते हैं, वहां से ट्रंक और टीडीडी पर वापस जा सकते हैं और देख सकते हैं कि अंतर क्या है।

— क़ुमराना

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

— लेनिप्रोग्राममर

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

— जेरेमी

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

— स्टीव 314

मैं लोकप्रिय राय के खिलाफ जा रहा हूं और कहता हूं कि अगर आप गेम बना रहे हैं तो TDD हमेशा सही विकल्प नहीं हो सकता है। चूंकि gamedev.stackexchange पर किसी ने पहले से ही इस प्रश्न का शानदार ढंग से उत्तर दिया है, मैं इसे यहाँ लिंक करूँगा ।

— l46kok

Answer 1

मुझे अपने अनुभव को साझा करने और अपनी चिंताओं को दूर करने के लिए धन्यवाद देने से शुरू करें ... जो मुझे कहना है कि वे असामान्य नहीं हैं।

• समय / उत्पादकता: लेखन परीक्षण परीक्षण न करने की तुलना में धीमा है। यदि आप इसे इसके दायरे में लेते हैं, तो मैं सहमत हो जाऊंगा। हालाँकि यदि आप एक गैर-टीडीडी दृष्टिकोण लागू करते हैं, तो संभावना है कि आप ब्रेक-डिटेक्ट-डिबग-एंड-फिक्स मौजूदा कोड को खर्च करने का मौका देते हैं और आपको नेट नकारात्मक में डाल देंगे। मेरे लिए, TDD सबसे तेज है, मैं अपने कोड-आत्मविश्वास से समझौता किए बिना जा सकता हूं। यदि आप अपनी विधि में ऐसी चीजें ढूंढते हैं, जो मूल्य नहीं जोड़ रहे हैं, तो उन्हें समाप्त करें।
• परीक्षणों की संख्या: यदि आप एन चीजों को कोड करते हैं, तो आपको एन चीजों का परीक्षण करने की आवश्यकता है। केंट बेक की लाइनों में से किसी एक को " अपने काम करने के लिए चाहो तो ही टेस्ट करो। "
• घंटों के लिए अटक जाना: मैं भी (कभी-कभी और> 20 मिनट पहले मैं लाइन रोक देता हूं) .. यह सिर्फ आपका कोड है जो आपको बता रहा है कि डिजाइन को कुछ काम करने की आवश्यकता है। आपके SUT वर्ग के लिए एक परीक्षण सिर्फ एक और ग्राहक है। यदि एक परीक्षण में आपके प्रकार का उपयोग करना मुश्किल हो रहा है, तो संभावना है कि आपके उत्पादन ग्राहक होंगे।
• इसी तरह के परीक्षण टेडियम: यह एक प्रतिवाद लिखने के लिए मेरे लिए कुछ और संदर्भ की आवश्यकता है। यह कहा, बंद करो और समानता के बारे में सोचो। क्या आप उन परीक्षणों को किसी तरह डाटा-ड्राइव कर सकते हैं? क्या आधार-प्रकार के खिलाफ परीक्षण लिखना संभव है? फिर आपको बस प्रत्येक व्युत्पत्ति के खिलाफ परीक्षणों का एक ही सेट चलाने की आवश्यकता है। अपने परीक्षणों को सुनो। सही तरह से आलसी बनें और देखें कि क्या आप टेडियम से बचने का तरीका जान सकते हैं।
• यह सोचने के लिए रुकना कि आपको आगे क्या करने की आवश्यकता है (परीक्षण / कल्पना) कोई बुरी बात नहीं है। इसके विपरीत, यह अनुशंसा की जाती है ताकि आप "सही बात" का निर्माण करें। आमतौर पर अगर मैं यह नहीं सोच सकता कि इसे कैसे जांचना है, तो मैं आमतौर पर कार्यान्वयन के बारे में सोच भी नहीं सकता। कार्यान्वयन विचारों को खाली करने के लिए यह एक अच्छा विचार है जब तक आप वहां नहीं पहुंच जाते हैं .. हो सकता है कि एक सरल समाधान एक YAGNI-ish पूर्व-खाली डिजाइन द्वारा निरीक्षण किया गया हो।

और यह मुझे अंतिम प्रश्न पर लाता है: मैं कैसे बेहतर हो सकता हूं? मेरा (या एक) उत्तर है , पढ़ें, प्रतिबिंबित और अभ्यास करें।

उदाहरण के लिए, मैं देर से नज़र रखता हूँ

• क्या मेरी लय RG [Ref] RG [Ref] RG [Ref] को दर्शाती है या यह RRRRGRRef है।
• लाल / संकलन त्रुटि स्थिति में बिताया गया समय।
• क्या मैं एक लाल / टूटे हुए राज्य में फंस गया हूं?

Comments

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

@ नैरोई - यह सुनिश्चित नहीं करें कि आप किस परीक्षण धावक का उपयोग कर रहे हैं। मैंने सिर्फ एक नाम सीखा, जो मैं बताना चाहता था। सार स्थिरता पैटर्न [ goo.gl/dWp3k] । इसके बाद भी आपको कई फिक्स्चर लिखने की आवश्यकता है क्योंकि ठोस प्रकार हैं। यदि आप और भी अधिक संक्षिप्त होना चाहते हैं, तो अपने धावक के डॉक्स देखें। जैसे NUnit Parameterized और Generic test जुड़नार का समर्थन करता है (अब जब मैंने इसके लिए खोज की थी) goo.gl/c1eEQ आपको जिस चीज़ की ज़रूरत है, वह पसंद करता है।

— गिशु

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

@asgeo - उस टिप्पणी को संपादित नहीं कर सकता है .. लिंक ने एक अनुगामी कोष्ठक उठाया है। यह काम करना चाहिए - goo.gl/dWp3k

— Gishu

+1 करने के लिए 'अटक जाना डिजाइन का लक्षण है और अधिक काम करने की जरूरत है', हालांकि .. क्या होता है जब आप डिजाइन में फंस जाते हैं (मेरे जैसे)?

— lurscher

Answer 2

आपको 100% प्रतिशत परीक्षण कवरेज की आवश्यकता नहीं है। व्यावहारिक हो।

Comments

यदि आपके पास 100% परीक्षण कवरेज नहीं है, तो आपके पास 100% आत्मविश्वास नहीं है।

— क्रिस्टोफर महान

100% टेस्ट कवरेज के साथ भी आपको 100% आत्मविश्वास नहीं है। यह परीक्षण 101 है। टेस्ट यह प्रदर्शित नहीं कर सकते कि कोड दोष-मुक्त है; इसके विपरीत, वे केवल यह प्रदर्शित कर सकते हैं कि इसमें दोष हैं।

— सीजरगॉन

इसके लायक क्या है, सबसे भावुक TDD अधिवक्ताओं में से एक, बॉब मार्टिन, 100% कवरेज की सिफारिश नहीं करता है - blog.objectmentor.com/articles/2009/01/31/… । विनिर्माण उद्योग में (कई मायनों में सॉफ्टवेयर से अलग), कोई भी 100% आत्मविश्वास के लिए नहीं जाता है क्योंकि वे 99% आत्मविश्वास होने के प्रयास का एक अंश खर्च कर सकते हैं।

— मौका

इसके अलावा (कम से कम पिछली बार मैंने जो उपकरण हमारे पास चेक किए थे) कोड कवरेज रिपोर्ट संबंधित हैं कि क्या लाइनों को निष्पादित किया गया था, लेकिन मूल्य कवरेज शामिल नहीं है - उदाहरण के लिए आज मेरे पास एक बग था, जहां मुझे परीक्षणों में निष्पादित कोड के माध्यम से सभी रास्ते थे, लेकिन चूँकि एक लाइन जैसी थी a = x + yऔर हालाँकि कोड में सभी लाइनों को परीक्षणों में निष्पादित किया गया था, परीक्षण केवल उस मामले के लिए परीक्षण किए गए जहां y = 0, इसलिए बग (यह होना चाहिए a = x - y) परीक्षणों में कभी नहीं पाया गया था।

— पीट किरकम

@ चांस - मैंने रॉबर्ट मार्टिन की किताब "क्लीन कोडर ..." कुछ लंबे नाम से पढ़ी है। उस पुस्तक में कहा गया है, कि यह asymptotically 100% परीक्षणों से ढंका होना चाहिए, जो कि 100% के करीब है। और ब्लॉग लिंक अब काम नहीं करता है।

— डेरियस .V

Answer 3

TDD अभी भी मुझे काफी धीमा कर रहा है

यह वास्तव में गलत है।

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

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

बीता हुआ समय शायद वही रहने वाला है। TDD सॉफ्टवेयर काफी बेहतर गुणवत्ता वाला होगा।

Comments

तो मुझे टीडीडी की आवश्यकता क्यों है? "बीता हुआ समय एक ही है"

@ पैटर लॉन्ग: कोड क्वालिटी। वर्ष "परीक्षण" है कि हम कैसे बकवास सॉफ्टवेयर के साथ हवा लेते हैं जो ज्यादातर काम करता है।

— २.११

@Peter, आप मजाक कर रहे हैं। टीडीडी समाधान की गुणवत्ता कहीं बेहतर होगी।

— मार्क थॉमस

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

@ पेटर लोंग: "बीता हुआ समय एक ही है" ... और उस समय किसी भी बिंदु पर आप कार्यशील कोड वितरित कर सकते हैं ।

— फ्रैंक शीयर

Answer 4

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

इससे मुझे आश्चर्य होता है कि आप टीडीडी के "रिफ्लेक्टर" कदम का कितना अनुसरण कर रहे हैं।

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

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

TDD के बारे में दार्शनिक बिंदुओं की एक जोड़ी जो सहायक हो सकती है:

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

EDIT: यूनिट टेस्टिंग के दर्शन के विषय पर, मुझे लगता है कि यह आपके लिए पढ़ना दिलचस्प हो सकता है: The Way of Testivus

और अधिक व्यावहारिक, यदि आवश्यक नहीं तो बहुत उपयोगी है, बिंदु:

• आप अपनी विकास भाषा के रूप में C ++ का उल्लेख करते हैं। मैंने JUnit और मॉकिटो जैसी उत्कृष्ट पुस्तकालयों का उपयोग करके, बड़े पैमाने पर Java में TDD का अभ्यास किया है। हालाँकि, मैंने सी ++ में टीडीडी पाया है जो पुस्तकालयों की कमी (विशेष रूप से, नकली रूपरेखा) के कारण बहुत निराशाजनक है। हालांकि यह बिंदु आपकी वर्तमान स्थिति में आपकी बहुत मदद नहीं करता है, लेकिन मुझे उम्मीद है कि आप टीडीडी को पूरी तरह से खोदने से पहले इस पर विचार कर लेंगे।

Comments

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

— स्कॉट व्हिटलॉक

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

— jaustin

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

— आनन

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

— नायरौ

Google C ++ मॉकिंग फ्रेमवर्क (Google C ++ टेस्ट fw के साथ एकीकृत) - बहुत, बहुत शक्तिशाली मॉकिंग लाइब्रेरी - लचीला, सुविधा संपन्न - किसी भी अन्य मॉकिंग फ्रेमवर्क के साथ काफी तुलनीय।

— चूहाकोन

Answer 5

बहुत ही रोचक सवाल।

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

मूल रूप से गेमिंग बहुत सारे जीयूआई, ध्वनि और धागे हैं। GUI, मानक घटकों के साथ भी आप WM_ को भेज सकते हैं, यूनिट-टेस्ट के लिए कठिन है।

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

तो फिर, मैं टीडीडी गुरु या इंजीलवादी नहीं हूं, इसलिए नमक के एक दाने के साथ यह सब ले लो।

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

एक त्रुटियों से संबंधित, C ++, RAII का चतुर उपयोग और एक अच्छा डिज़ाइन उन्हें रोकने के लिए एक लंबा रास्ता तय करता है।

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

Comments

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

— मार्क हीथ

@Mark: हाँ, कोई भी आजकल एकीकरण परीक्षणों की परवाह नहीं करता है, यह सोचकर कि उन्हें एक स्वचालित परीक्षण सूट मिल गया है, सब कुछ एक साथ डालते समय जादुई काम करते हैं और वास्तविक डेटा के साथ बाहर की कोशिश करते हैं।

— gbjbaanb

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

— jb

Answer 6

मैं अन्य उत्तरों से सहमत हूं, लेकिन मैं एक बहुत महत्वपूर्ण बिंदु जोड़ना चाहता हूं: लागत को फिर से भरना !!

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

Answer 7

अन्य लोग सभी उत्पादकता और प्रेरणा की हत्या किए बिना टीडीडी को कैसे बचाते हैं?

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

टीडीडी यह जानने की विनम्रता रखता है कि आप (और मैं!) गलतियाँ करते हैं।

मेरे लिए समय लेखन unittests शुरू से TDD का उपयोग कर किया जाता है कि परियोजनाओं के लिए कम डिबगिंग समय में बचाया से अधिक है।

यदि आप गलतियाँ नहीं करते हैं तो शायद टीडीडी आपके लिए उतना महत्वपूर्ण नहीं है जितना कि यह मेरे लिए है!

Comments

ठीक है, आपके पास अपने TDD कोड में कीड़े हैं;)

— कोडर

ये सत्य है! लेकिन अगर वे TDD ठीक से किया जाता है, तो वे एक अलग प्रकार की बग बनाते हैं। मुझे लगता है कि कोड को 100% बग मुक्त होने के लिए स्वतंत्र होना सही नहीं है। यद्यपि यदि कोई एक बग को इकाई परीक्षण परिभाषित व्यवहार से विचलन के रूप में परिभाषित करता है, तो मुझे लगता है कि यह बग मुक्त है :)

— टॉम

Answer 8

मैंने केवल कुछ टिप्पणी की है:

1. ऐसा लगता है कि आप हर चीज को परखना चाहते हैं । आपको शायद कोड / विधि के किसी विशेष टुकड़े के उच्च-जोखिम और किनारे के मामलों को नहीं करना चाहिए। मुझे पूरा यकीन है कि 80/20 नियम यहां लागू होता है: आप अपने कोड या कवर नहीं किए गए मामलों के अंतिम 20% के लिए 80% लेखन परीक्षण खर्च करते हैं।

2. को प्राथमिकता दें। चुस्त सॉफ्टवेयर विकास में जाओ, और एक महीने के समय में रिलीज करने के लिए आपको वास्तव में वास्तव में क्या करने की आवश्यकता है उसकी एक सूची बनाएं। फिर रिलीज, ऐसे ही। यह आपको सुविधाओं की प्राथमिकता के बारे में सोचने देगा। यदि आपका चरित्र एक बैकफ़्लिप कर सकता है, तो हाँ, यह अच्छा होगा, लेकिन क्या इसका व्यावसायिक मूल्य है ?

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

Answer 9

हां, लेखन परीक्षण और कोड को लिखने के कोड से अधिक समय लग सकता है - लेकिन कोड लिखना और संबंधित इकाई परीक्षण (TDD का उपयोग करना) कोड लिखने की तुलना में बहुत अधिक अनुमानित है और फिर इसे डीबग करना है।

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

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

Answer 10

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