टेस्ट संचालित विकास - मुझे मनाओ! [बन्द है]

Question

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

1. आप किन परियोजनाओं के लिए परीक्षण-संचालित विकास का उपयोग करते हैं? क्या आप केवल एक निश्चित आकार से ऊपर की परियोजनाओं के लिए इसका उपयोग करते हैं?
2. मुझे इसका उपयोग करना चाहिए या नहीं? मुझे समझाओ!

Comments

मुझे सिर्फ टेस्ट लिखने में इतनी परेशानी होती है। इसका मतलब उस बिंदु पर है जहां मैं सिर्फ मैन्युअल रूप से सब कुछ सत्यापित करता हूं।

— TheLQ

इस प्रश्न पर एक नज़र डालें: stackoverflow.com/questions/301693/…

— systempuntoout

@ TheLQ ... अपने ग्राहक को यह बताने का प्रयास करें कि मेरा फ़्लाइट-कंट्रोल सॉफ्टवेयर ठीक है क्योंकि मैंने मैन्युअल कोड की समीक्षा की है :-)

— एंड्रयू

Answer 1

ठीक है, TDD के कुछ फायदे:

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

आपने आश्वस्त होने के लिए कहा, इसलिए ये लाभ थे। देखें इस सवाल का एक और अधिक संतुलित देखने के लिए।

Comments

"परीक्षण योग्य डिज़ाइन लगभग हमेशा बेहतर डिज़ाइन होता है" - मुझे लगता है कि इसका मुख्य कारण है क्योंकि परीक्षण योग्य कोड आमतौर पर मॉड्यूलर होता है और सरलता निर्भरता के साथ होता है।

— स्किलड्रिक

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

— १

@ डैरनव- मुझे आपके बारे में पता नहीं है, लेकिन मैं चीजों को तोड़ने के बजाय काम करना चाहूंगा। उस ने कहा, कोई व्यक्ति जो आपको सुझाव देने के तरीके को सोचता है वह एक परीक्षक के रूप में हेला-मूल्यवान है। दुनिया में पर्याप्त गुणवत्ता वाले क्यूए लोग नहीं हैं।

— फिशटोस्टर

मुझे उस पीडीएफ में 403 निषिद्ध त्रुटि मिल रही है

— नील एन

अपडेट किया गया है कि मुझे यकीन है कि एक ही पीडीएफ था (यह कुछ साल पहले था)

— फिशटोस्टर

Answer 2

रॉबर्ट सी। मार्टिन ने मूल रूप से इन बिंदुओं को बनाया - मैं उन्हें अपने अनुभव से वापस कर सकता हूं:

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

मैं हर समय टीडीडी को बहुत पसंद करता हूं, चाहे मैं उत्पादन या प्ले कोड पर काम कर रहा हूं; मुझे इन दिनों किसी अन्य तरीके से कोड करना मुश्किल लगता है।

Answer 3

(अस्वीकरण: मैं शायद ही कोई यूआई सामान करता हूं, इसलिए मैं यूआई के लिए टीडीडी पर चर्चा नहीं कर सकता।)

मैं टीडीडी से लेकर तुच्छ ऐप तक पूरे एसआईपी स्टैक में बहुत कुछ करता हूं।

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

Answer 4

• जब भी आपके ग्राहक को अधिक प्रभावी ढंग से आपूर्ति की जा सकती है (वे संभवतः परीक्षणों से अच्छी तरह से संबंधित होंगे - और यह कम से कम परियोजना की चर्चा पर कटौती करेगा)
• जब भी यह आपके सह-डेवलपर्स को कोड में EVERYTYHING पर सूचित करने में अधिक समय लगेगा, परीक्षण के निर्माण में प्रयास करने की तुलना में - और यह जितनी जल्दी आप सोच सकते हैं

Answer 5

क्या? कोई नकारात्मक जवाब नहीं !?

अस्वीकरण: मैं यूनिट-परीक्षण विरोधी नहीं हूं। जब लोग TDD कहते हैं, तो मुझे लगता है कि उनका मतलब बीमारी-लगने वाले संस्करण से है जहां वे परीक्षण लिख रहे हैं इससे पहले कि वे जो भी कोड लिखते हैं उसका 80-100% कोड लिखें।

मैं तर्क करूँगा:

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

• यह लोगों को वास्तविक समस्या को अनदेखा करने में मदद करता है। जब एक बग को ठीक करना अजीब-ए-मोल के खेल में बदल जाता है, जहां दो और पॉप-अप होते हैं, तो आर्किटेक्चर खिलता है। ध्यान दें। वास्तविक समस्या पर ध्यान दें। इससे पहले कि वे whacked होना चाहिए मोल्स देख रहा है साफ-ओ लेकिन आप पहली जगह में नहीं होना चाहिए।

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

• डिज़ाइन फ़ोकस: बिल्कुल कोई तरीका नहीं है यहां तक ​​कि एक अच्छा डेवलपर भी सबसे अच्छा कोड लिखने जा रहा है जब वे टेस्ट पर भी ध्यान केंद्रित कर रहे हैं। यदि यह एकमात्र तरीका है जैसा कि आप एक सभ्य डिजाइन हो सकता है, मैं ऊपर "वास्तविक समस्या पर ध्यान केंद्रित करने" के बारे में देखने की सलाह दूंगा।

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

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

Comments

डीए डाउनवोटर्स केवल हेडलाइन क्यू को पढ़ते हैं न कि कंटेंट को।

— एरिक रेपेने

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

— सारा