क्या TDD वास्तव में जटिल परियोजनाओं के लिए काम करता है?

53

मैं TDD परियोजनाओं के दौरान अनुभव की गई समस्याओं के संबंध में यह प्रश्न पूछ रहा हूं। मैंने यूनिट परीक्षण बनाते समय निम्नलिखित चुनौतियों पर ध्यान दिया है।

नकली डेटा बनाना और बनाए रखना

बड़े नकली डेटा को बनाए रखना कठिन और अवास्तविक है। डेटाबेस संरचना में परिवर्तन होने पर यह और भी कठिन है।

परीक्षण जीयूआई

यहां तक कि MVVM और GUI का परीक्षण करने की क्षमता के साथ, यह GUI परिदृश्य को पुन: पेश करने के लिए बहुत सारे कोड लेता है।

व्यवसाय का परीक्षण

मुझे अनुभव है कि अगर आप इसे सरल व्यापार तर्क तक सीमित करते हैं तो TDD अच्छा काम करता है। हालांकि जटिल व्यावसायिक तर्क परीक्षण करना कठिन है क्योंकि परीक्षणों के संयोजन की संख्या (परीक्षण स्थान) बहुत बड़ी है।

आवश्यकताओं में विरोधाभास

वास्तव में विश्लेषण और डिजाइन के तहत सभी आवश्यकताओं को पकड़ना मुश्किल है। कई बार एक नोट की आवश्यकताएं विरोधाभास की ओर ले जाती हैं क्योंकि परियोजना जटिल है। विरोधाभास कार्यान्वयन चरण के तहत देर से मिला है। टीडीडी के लिए आवश्यक है कि आवश्यकताएं 100% सही हों। ऐसे मामलों में कोई यह उम्मीद कर सकता है कि परीक्षणों के निर्माण के दौरान परस्पर विरोधी आवश्यकताओं को पकड़ लिया जाएगा। लेकिन समस्या यह है कि जटिल परिदृश्यों में ऐसा नहीं है।

मैंने यह प्रश्न पढ़ा है: TDD काम क्यों करता है?

क्या TDD वास्तव में जटिल उद्यम परियोजनाओं के लिए काम करता है, या क्या यह व्यावहारिक रूप से परियोजना प्रकार तक सीमित है?

tdd

— अमीर रज़ाई
स्रोत

+1 उस प्रश्न को पढ़ने के बाद मेरे पास एक ही सवाल था - मैं इसे सीमित अर्थों में नकली डेटा के साथ समस्या के साथ उपयोग करता हूं।

— माइकल के

20

"TDD के लिए आवश्यक है कि आवश्यकताएं 100% सही हों" जहां "आवश्यकताओं" का अर्थ है "मुझे यह जानने की आवश्यकता है कि इस एकल विधि को कैसे काम करना चाहिए"। और यदि आप नहीं जानते कि विधि कैसे काम करने वाली है, तो आप इसे कैसे लागू करेंगे?

— फ्रैंक शीयर

@FrankShearar: आप जानते हैं कि अपेक्षित इनपुट पर कैसे काम करना चाहिए। कहें कि स्ट्रैम्प को 2 पॉइंट लेने चाहिए, जिनमें से कोई भी शून्य नहीं है और दोनों वैध हैं। आपको नहीं पता कि जब आप खराब पॉइंटर खिलाएंगे तो क्या होगा। शायद कुछ आर्किटेक्चर पर आप एवी को पकड़ सकते हैं और कुछ समझदार कर सकते हैं, लेकिन आप कल्पना नहीं कर सकते कि ऐसा परिदृश्य संभव है, इसलिए आपके परीक्षण इसे कवर नहीं कर रहे हैं।

— कोडर

7

मैं कहूंगा कि TDD केवल एक चीज है जो बड़ी परियोजनाओं के लिए काम करती है! प्रोजेक्ट जितना बड़ा होगा उतने ही जटिल और अधिक आवश्यकताएं बेतरतीब ढंग से बदलती हैं - केवल TDD रख सकते हैं

— मार्टिन बेकेट

2

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

— जॉर्डन रीटर

53

बड़े नकली डेटा को बनाए रखना कठिन और अवास्तविक है। डेटाबेस संरचना में परिवर्तन होने पर यह और भी कठिन है।

असत्य।

यूनिट परीक्षण के लिए "बड़े" नकली डेटा की आवश्यकता नहीं है। परिदृश्यों का परीक्षण करने के लिए पर्याप्त मॉक डेटा की आवश्यकता होती है और इससे अधिक कुछ नहीं।

इसके अलावा, वास्तव में आलसी प्रोग्रामर विषय विशेषज्ञों को विभिन्न परीक्षण मामलों के सरल स्प्रैडशीट बनाने के लिए कहते हैं। बस एक सरल स्प्रेडशीट है।

फिर आलसी प्रोग्रामर स्प्रेडशीट पंक्तियों को यूनिट टेस्ट मामलों में बदलने के लिए एक सरल स्क्रिप्ट लिखता है। यह वास्तव में बहुत आसान है।

जब उत्पाद विकसित होता है, तो परीक्षण मामलों के स्प्रेडशीट को अपडेट किया जाता है और नई इकाई परीक्षण उत्पन्न होते हैं। हर समय करें। यह सचमुच काम करता है।

एमवीवीएम और जीयूआई का परीक्षण करने की क्षमता के साथ, यह जीयूआई परिदृश्य को पुन: पेश करने के लिए बहुत सारे कोड लेता है।

क्या? "पुन"?

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

मुझे अनुभव है कि अगर आप इसे सरल व्यापार तर्क तक सीमित करते हैं तो TDD अच्छा काम करता है। हालांकि जटिल व्यावसायिक तर्क परीक्षण करना कठिन है क्योंकि परीक्षण (परीक्षण स्थान) के संयोजन की संख्या बहुत बड़ी है।

यह सच हो सकता है।

हालाँकि, विषय वस्तु विशेषज्ञों से कोर टेस्ट के मामलों को एक सरल रूप में प्रस्तुत करना (स्प्रेडशीट की तरह) वास्तव में मदद करता है।

स्प्रेडशीट बड़े नहीं बल्कि बन सकते हैं। लेकिन यह ठीक है, क्योंकि मैंने स्प्रेडशीट को परीक्षण के मामलों में बदलने के लिए एक साधारण पायथन स्क्रिप्ट का उपयोग किया था।

तथा। मुझे कुछ परीक्षण मामलों को मैन्युअल रूप से लिखना पड़ा क्योंकि स्प्रेडशीट अधूरी थी।

हालाँकि। जब उपयोगकर्ताओं ने "बग" की सूचना दी, तो मैंने बस पूछा कि स्प्रेडशीट में कौन सा परीक्षण मामला गलत था।

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

विशेषज्ञों को सुनने के बजाय एक सुपर-कॉम्प्लेक्स व्यावसायिक प्रक्रिया को समझाने की कोशिश करें, विशेषज्ञों को प्रक्रिया के ठोस उदाहरणों का उत्पादन करना होगा।

टीडीडी के लिए आवश्यक है कि आवश्यकताएं 100% सही हों। ऐसे मामलों में कोई यह उम्मीद कर सकता है कि परीक्षणों के निर्माण के दौरान परस्पर विरोधी आवश्यकताओं को पकड़ लिया जाएगा। लेकिन समस्या यह है कि जटिल परिदृश्य में ऐसा नहीं है।

TDD का उपयोग न करना बिल्कुल अनिवार्य है कि आवश्यकताएँ 100% सही हों। कुछ का दावा है कि टीडीडी अपूर्ण और बदलती आवश्यकताओं को सहन कर सकता है, जहां एक गैर-टीडीडी दृष्टिकोण अपूर्ण आवश्यकताओं के साथ काम नहीं कर सकता है।

यदि आप टीडीडी का उपयोग नहीं करते हैं, तो विरोधाभास कार्यान्वयन चरण के तहत देरी से पाया जाता है।

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

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

— S.Lott
स्रोत

4

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

— एरॉन मैकिवर

3

@ S.Lott यह स्कोप पर निर्भर करता है। टीडीडी एक दृश्य के परीक्षण के संबंध में पर्याप्त मूल्य प्रदान नहीं करता है। हालांकि TDD मॉडल और ViewModel के परीक्षण के संबंध में पर्याप्त मूल्य प्रदान करता है। यदि आपका दायरा ViewModel और View था, तो TDD का मान आपके दायरे के आधार पर बहुत अलग होगा, यदि आपका दायरा मॉडल और आवश्यक सेवाएं थीं। मुझे गलत मत समझो, मेरा मानना है कि टीडीडी के पास जटिल परियोजनाओं में पर्याप्त मूल्य है ... इसका मूल्य बस गुंजाइश के आधार पर भिन्न होता है।

— एरोन मैकिवर

5

@ रॉबर्ट हार्वे: यह मेरा आविष्कार नहीं हो सकता। मैं कुछ भी आविष्कार करने के लिए बहुत आलसी हूं।

— लोट

4

@Amir Rezaei: मुझे खेद है कि आपकी न्यूनतम इकाई परीक्षण डेटा जटिल है। जिसका TDD से कोई लेना-देना नहीं है। आपका आवेदन जटिल है। आपको अभी भी इसे परीक्षण करने की आवश्यकता है, है ना? आपको अभी भी परीक्षण डेटा का उत्पादन करना चाहिए? यदि आप TDD का पालन नहीं करने जा रहे हैं, तो आप एक परीक्षण योग्य एप्लिकेशन कैसे बना सकते हैं? भाग्य? आशा है कि? हाँ। यह जटिल है। कुछ भी जटिलता को दूर नहीं करता है। टीडीडी ने आश्वासन दिया कि आप वास्तव में उस जटिलता का परीक्षण करेंगे।

— एस.लॉट

4

@ एमीर रज़ाई: "हम वास्तविकता के लिए डिज़ाइन कर रहे हैं"। क्या आप परीक्षण लिखने जा रहे हैं? यदि ऐसा है, तो परीक्षण क्षमता के लिए डिज़ाइन करें। यदि आप परीक्षण लिखने के लिए नहीं जा रहे हैं, तो आप कुछ काम कैसे जानेंगे?

— S.Lott

28

हाँ

TDD के लिए मेरा पहला एक्सपोजर लिनक्स-आधारित सेल फोन के लिए मिडिलवेयर घटकों पर काम कर रहा था। अंततः स्रोत कोड की लाखों लाइनें होने के कारण घाव हो जाता है, जो विभिन्न ओपन-सोर्स घटकों के लिए लगभग 9 गीगाबाइट स्रोत कोड में कहा जाता है।

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

टीडीडी और कम से कम भाग के कारण कोई संदेह नहीं है कि सभी इकाई परीक्षण हमेशा पास होते हैं, 1.0 रिलीज जल्दी, बजट के तहत, और आश्चर्यजनक स्थिरता के साथ आया।

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

— बॉब मर्फी
स्रोत

8

removed the requirement that unit tests pass. It was astonishing how quickly quality went down the toilet, and then the schedule followed it.

- यह अपने F1 ड्राइवर को बताने जैसा है कि उसे पिट स्टॉप्स की अनुमति नहीं है क्योंकि इसमें बहुत अधिक समय लगता है ... आइडियोटिक।

— जेस टेलफ़ोर्ड

1

यह मुझे जो कहता रहता है उसका अनुकरण करता है: तेजी से जाने का एकमात्र तरीका अच्छी तरह से जाना है !

— दैटविस्परर

18

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

a) आपको अपने डिज़ाइन के बहुत पहले से मान्यता प्राप्त है, क्योंकि आपके फीडबैक लूप गेट गो से परीक्षणों के कारण बहुत तंग है।

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

ग) समाप्त कोड परिणाम के रूप में बहुत बेहतर होगा।

— व्याट बार्नेट
स्रोत

1

मैं टीडीडी के लाभों को देखता हूं और जानता हूं। हालांकि मैं इस बात पर बहस करता हूं कि ऐसी परियोजनाओं में टीडीडी करने के लिए कितना यथार्थवादी और कितना संसाधन और खर्च करने की जरूरत है।

— आमिर रज़ाई

मुझे आपसे सहमत होना होगा। जटिल परियोजनाओं में (मेरी राय में) यह सुनिश्चित करने का कोई अन्य तरीका नहीं है कि सब कुछ परीक्षणों की तुलना में काम करता है ... यदि कई प्रोग्रामर आप पर कोड-बेस काम करते हैं, तो आप यह सुनिश्चित नहीं कर सकते हैं कि किसी ने आपके काम करने के सामान को बदल नहीं दिया है। यदि परीक्षा पास होती रहती है - कोई समस्या नहीं। यदि नहीं, तो आप जानते हैं कि कहाँ देखना है।

— मैहर

10

क्या TDD वास्तव में जटिल परियोजनाओं के लिए काम करता है?
हाँ। हर प्रोजेक्ट ऐसा नहीं है, जिसके बारे में मुझे बताया गया है कि टीडीडी के साथ अच्छी तरह से काम करता है, लेकिन अधिकांश व्यावसायिक अनुप्रयोग ठीक हैं, और मैं शर्त लगाता हूं कि जब वे शुद्ध टीडीडी तरीके से लिखे गए हैं तो वे अच्छी तरह से काम नहीं करते हैं, बिना प्रमुख मुद्दों के बिना एटीटीडी तरीके से लिखा जा सकता है।

नकली डेटा को उत्पन्न करना और बनाए
रखना इसे छोटा रखें और केवल आपके पास ही इसकी आवश्यकता है और ऐसा लगता है कि यह डरावना मुद्दा नहीं है। मुझे गलत मत समझो, यह एक दर्द है। लेकिन यह सार्थक है।

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

व्यवसाय का परीक्षण करना
एक मुद्दा नहीं पाया गया। छोटे परीक्षण के बहुत सारे। जैसा कि मैंने ऊपर कहा था, कुछ मामले (सुडोकू पहेली सॉल्वर एक लोकप्रिय लगता है) स्पष्ट रूप से टीडीडी करना मुश्किल है।

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

— MLK
स्रोत

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

— आमिर रज़ाई

एक "यूनिट" एक आवश्यकता से छोटी होती है, और हाँ आम तौर पर सभी यूएसी को बंधे बिना किया जा सकता है।

— एमके

हम प्रत्येक यूनिट का यूनिट टेस्ट करते हैं और यूनिट्स का यूनिट टेस्ट संयोजन भी, यही आवश्यकता है।

— अमीर रज़ाई

9

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

बड़े नकली डेटा को बनाए रखना कठिन और अवास्तविक है।

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

डेटाबेस संरचना में परिवर्तन होने पर यह और भी कठिन है।

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

यहां तक कि MVVM और GUI का परीक्षण करने की क्षमता के साथ, यह GUI परिदृश्य को पुन: पेश करने के लिए बहुत सारे कोड लेता है।

आप सही हैं, GUI (दृश्य) का परीक्षण करना यूनिट के लिए आसान नहीं है, और कई लोग इसके बिना अच्छा कर रहे हैं (इसके अलावा, GUI का परीक्षण करना TDD का हिस्सा नहीं है)। इसके विपरीत, यूनिट आपके नियंत्रक / प्रस्तुतकर्ता / ViewModel / जो भी मध्यवर्ती परत की अत्यधिक अनुशंसा की जाती है, वास्तव में इसका मुख्य कारण है कि MVC या MVVM जैसे पैटर्न हैं।

मुझे अनुभव है कि अगर आप इसे सरल व्यापार तर्क तक सीमित करते हैं तो TDD अच्छा काम करता है। हालांकि जटिल व्यावसायिक तर्क परीक्षण करना कठिन है क्योंकि परीक्षणों के संयोजन की संख्या (परीक्षण स्थान) बहुत बड़ी है।

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

टीडीडी के लिए आवश्यक है कि आवश्यकताएं 100% सही हों।

बिलकुल नहीं। सफल सॉफ़्टवेयर के लिए आवश्यक है कि आवश्यकताएं 100% सही हों;) यूनिट परीक्षण केवल यह दर्शाता है कि वर्तमान में आपकी आवश्यकताओं की दृष्टि क्या है; यदि दृष्टि त्रुटिपूर्ण है, तो आपका कोड और आपका सॉफ्टवेयर भी होगा, इकाई परीक्षण या नहीं ... और यही वह जगह है जहाँ इकाई परीक्षण चमकते हैं: स्पष्ट रूप से पर्याप्त परीक्षण शीर्षक के साथ, आपके डिजाइन निर्णय और आवश्यकताओं की व्याख्या पारदर्शी हो जाती है, जिससे बात करना आसान हो जाता है अगली बार जब आपके ग्राहक को यह कहने की ज़रूरत है कि आपकी उंगली बदल गई है, "यह व्यवसाय नियम वैसा नहीं है जैसा मैं चाहता हूँ"।

— guillaume31
स्रोत

6

जब मैं किसी की शिकायत सुनता हूं तो मुझे हंसी आती है कि वे अपने आवेदन का परीक्षण करने के लिए टीडीडी का उपयोग नहीं कर सकते क्योंकि उनका आवेदन इतना जटिल है। विकल्प क्या है? परीक्षण बंदरों को कीबोर्ड की एकर पर तेज़ करना है? उपयोगकर्ताओं को परीक्षक होने दें? और क्या? बेशक यह कठिन और जटिल है। क्या आपको लगता है कि इंटेल उनके चिप्स का परीक्षण नहीं करता है जब तक वे जहाज नहीं करते हैं? "हेड-इन-द-सैंड" वह कैसे है?

— SnoopDougieDoug
स्रोत

5

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

— कोडर

एक विकल्प प्रतिगमन परीक्षण है। वेब ब्राउज़र का परीक्षण करने के बारे में सोचें, कहें। मान लीजिए कि आप Google हैं और आप Chrome के नए संस्करण का परीक्षण करना चाहते हैं। आप प्रत्येक व्यक्तिगत सीएसएस तत्व, और प्रत्येक HTML टैग की प्रत्येक विशेषता और जावास्क्रिप्ट को कर सकने वाली हर तरह की बुनियादी चीज़ों का परीक्षण कर सकते हैं। लेकिन इन सुविधाओं के कितने संभावित संयोजन हैं? मुझे नहीं लगता कि कोई भी संभवतः यह जान सकता है। इसलिए वे विभिन्न प्रकारों में व्यक्तिगत विशेषताओं के सभी प्रकार के परीक्षण करते हैं, लेकिन अंततः, वे वेबसाइटों के एक ज्ञात बैंक के खिलाफ प्रतिगमन चलाते हैं। वहीं पर दस लाख बंदर हैं।

— दान कोर्न

यथार्थवादी विकल्प सॉफ्टवेयर देने के लिए है जो काम नहीं करता है; सही परिस्थितियों में, यह अभी भी लाभदायक हो सकता है। अपना पसंदीदा उदाहरण चुनें।

— सोरू

4

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

— dsimcha
स्रोत

मुझे यह समस्या हुई है। आपको "हाथ से" काम करने के लिए सरल मामलों की आवश्यकता है, और एक पर्याप्त जटिल मामले ने एक डोमेन विशेषज्ञ द्वारा काम किया और मान्य किया है। यदि कोई ऐसा नहीं कर सकता है, तो आपके पास एक विनिर्देशन समस्या है। जब आप एक एल्गोरिथम स्वीकृति फ़ंक्शन को एन्कोड कर सकते हैं, भले ही वह सही आकार की स्थिति को न

— छोड़े

"और एक पर्याप्त रूप से जटिल मामले ने काम किया और एक डोमेन विशेषज्ञ द्वारा मान्य" - यह एक इकाई परीक्षण तो, या एक प्रतिगमन परीक्षण है?

— quant_dev

2

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

— dsimcha

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

— टिम विलिसक्रॉफ्ट

@dsimcha: इसलिए इकाई परीक्षण के लिए एक सांख्यिकीय दृष्टिकोण आपके लिए काम कर सकता है, जैसा कि आप अनुमानित अनुमान लगा सकते हैं। मैं एक हथियार प्रणाली में इस दृष्टिकोण का उपयोग करता था और चलती लक्ष्य को स्थानांतरित करने, शूटर सगाई कोड को स्थानांतरित करने के लिए। हाथ से उस के लिए जवाब देना बहुत मुश्किल है, लेकिन यह कहना आसान है कि भविष्यवक्ता ने काम किया है (आप वास्तव में एक प्रक्षेप्य आग लगाते हैं, और देखें कि यह वास्तव में कहाँ हिट करता है, बल्कि, 100000 बार एनडी को दोहराता है एन डी आपको अच्छे परिणाम मिलते हैं जैसे कि "एल्गोरिथम" A 91% समय में काम करता है, AlgorithmB 85% समय काम करता है।)

— टिम विस्क्रॉफ्ट

4

> Does TDD really work for complex projects?

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

हालाँकि, मुझे इस बात की आशंका नहीं है कि TDD आपके द्वारा BDD- शैली परीक्षणों के साथ एकीकरण या एंड-टू-एंड परीक्षण पर बताई गई समस्याओं को हल कर सकता है ।

लेकिन कम से कम कुछ समस्याओं को कम किया जा सकता है ।

> However complex business logic is hard to test since the number 
> of combinations of tests (test space) is very large.

यह सच है अगर आप एकीकरण-परीक्षण या एंड-टू-एंड परीक्षण के स्तर पर पूर्ण कवरेज करना चाहते हैं। यह आसान हो सकता है कि एक गैर-स्तर पर पूर्ण कवरेज कर रहा हो।

उदाहरण: जटिल उपयोगकर्ता अनुमतियों की जाँच करना

IsAllowedToEditCusterData()एकीकरण-परीक्षण स्तर पर फ़ंक्शन का परीक्षण करने के लिए उपयोगकर्ता, डोमेन, ग्राहक, पर्यावरण .... के बारे में जानकारी के लिए विभिन्न वस्तुओं को पूछना होगा।

इन भागों का मजाक उड़ाना काफी अलग है। यह विशेष रूप से सच है अगर IsAllowedToEditCusterData()इन विभिन्न वस्तुओं को जानना है।

यूनीटेस्ट-लेवल पर आपके पास फंक्शन होगा जो IsAllowedToEditCusterData()उदाहरण के लिए 20 पैरामीटर लेता है जिसमें फ़ंक्शन को जानने के लिए आवश्यक सभी कुछ होता है। चूंकि IsAllowedToEditCusterData()यह जानने की जरूरत नहीं है कि ए user, ए domain, ए customer... किन क्षेत्रों में परीक्षण करना आसान है।

जब मुझे लागू करना IsAllowedToEditCusterData()था तो मुझे इसके दो ओवरलोड थे:

एक अधिभार जो उन 20 मापदंडों को प्राप्त करने से ज्यादा कुछ नहीं करता है और फिर निर्णय लेने वाले 20 मापदंडों के साथ अधिभार को बुलाता है।

(मेरे IsAllowedToEditCusterData()पास केवल 5 पैरामीटर थे और मुझे पूरी तरह से परीक्षण करने के लिए 32 विभिन्न संयोजनों की आवश्यकता थी)

उदाहरण

// method used by businesslogic
// difficuilt to test because you have to construct
// many dependant objects for the test
public boolean IsAllowedToEditCusterData() {
    Employee employee = getCurrentEmployee();
    Department employeeDepartment = employee.getDepartment();
    Customer customer = getCustomer();
    Shop shop = customer.getShop();

    // many more objects where the permittions depend on

    return IsAllowedToEditCusterData(
            employee.getAge(),
            employeeDepartment.getName(),
            shop.getName(),
            ...
        );
}

// method used by junittests
// much more easy to test because only primitives
// and no internal state is needed
public static boolean IsAllowedToEditCusterData(
        int employeeAge,
        String employeeDepartmentName,
        String shopName,
        ... ) 
{
    boolean isAllowed; 
    // logic goes here

    return isAllowed;
}

— के 3 बी
स्रोत

1

+1 बहुत अच्छा उदाहरण "जटिल उपयोगकर्ता अनुमतियों की जाँच" जो हमारे परिदृश्यों में से एक है।

— आमिर रज़ाई

3

दुखद उत्तर यह है कि वास्तव में बड़ी जटिल परियोजनाओं के लिए कुछ भी काम नहीं करता है!

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

— जेम्स एंडरसन
स्रोत

1

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

"Wtf। यह कोड शाखा वहां भी क्यों है? पता नहीं, हो सकता है कि किसी को इसकी आवश्यकता हो, किसी को परेशान करने के बजाय इसे बेहतर छोड़ दें ..." समय के साथ जटिल परियोजनाएं एक कचरा भूमि बन जाती हैं।

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

— kizzx2
स्रोत

1

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

इस समस्या को ठीक करने का तरीका क्लाइंट साइट पर डीबगर में आग लगाना होगा, वास्तविक डेटा के खिलाफ रहना, कोड के माध्यम से कदम, ब्रेक पॉइंट के साथ, वॉच चर, घड़ी मेमोरी, आदि। हालांकि, यह टीम, किसने सोचा था कि उनका कोड हाथी दांत के बेहतरीन टावरों को सँवारने के लायक होगा, लगभग एक साल की अवधि में कभी भी इस ऐप को नहीं हटाया गया। जिसने मेरे दिमाग को उड़ा दिया।

तो, सब कुछ की तरह, संतुलन कुंजी है। TDD अच्छा हो सकता है, लेकिन इस पर विशेष रूप से भरोसा नहीं करते।

— एसपीए
स्रोत

1

टीडीडी मूढ़ता को नहीं रोकता है। TDD फुर्तीले होने का एक हिस्सा है, लेकिन एक और महत्वपूर्ण बिट प्रत्येक स्प्रिंट में निष्पादन योग्य, रन करने योग्य कोड देने के बारे में है ...

— ऑलिगॉफ्रेन

0

मुझे लगता है कि, टेस्ट ड्रिवेन डेवलपमेंट वास्तव में काम करता है

2008 में, नचियप्पन नागप्पन, ई। माइकल मैक्सिमिलीन, थिरुमलेश भट, और लॉरी विलियम्स ने एक पेपर लिखा जिसका नाम था "परीक्षण संचालित विकास के माध्यम से गुणवत्ता में सुधार: चार औद्योगिक टीमों के परिणाम और अनुभव" (पीडीएफ लिंक)। सार:

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

2012 में, रूबी ऑन रेल डेवलपमेंट प्रथाएं टीडीडी मानती हैं। मैं व्यक्तिगत रूप से परीक्षण और नकली लिखने के लिए rspec जैसे उपकरणों पर भरोसा करता हूं, ऑब्जेक्ट बनाने के लिए factory_girl, ब्राउज़र ऑटोमेशन के लिए कापीबारा, कोड कवरेज के लिए सिंपकोव और इन परीक्षणों को स्वचालित करने के लिए गार्ड।

इस पद्धति और इन उपकरणों का उपयोग करने के परिणामस्वरूप, मैं नागप्पन एट अल के साथ विषय से सहमत हूं ...

— Hiltmon
स्रोत

0

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

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

TDD परियोजना पर, इस आसन्न विफलता का लक्षण यह है कि परीक्षण अनुसूची पर नहीं लिखे जा सकते हैं; आप कोशिश करते हैं, केवल यह पता लगाने के लिए कि ' यह समय लगेगा और हमारे पास केवल यही है '।

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

— soru
स्रोत

-1

TDDदर्द के रूप में ध्वनि हो सकती है लेकिन लंबे समय में यह आपका सबसे अच्छा दोस्त होगा, मुझे विश्वास है TDDकि वास्तव में लंबे समय में आवेदन को बनाए रखने और सुरक्षित बना देगा।

— राहेल
स्रोत