परीक्षण संचालित विकास पर

Question

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

Answer 1

यदि आप पहले अपने परीक्षण नहीं लिखते हैं तो यह तर्कसंगत रूप से टीडीडी नहीं है। टीडीडी के साथ आप आम तौर पर परीक्षण लिखते हैं, इसे असफल देखते हैं, फिर इसे पास करने के लिए कार्यान्वित करते हैं।

अपने कार्यप्रवाह से अधिक लाभ हैं:

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

आप उन सभी बिंदुओं के जोखिमों को कम कर सकते हैं, इसलिए यह आपके लिए नीचे है कि आप जिस तरह से जा रहे हैं या पहले परीक्षण करने के लिए स्विच करना चाहते हैं।

Answer 2

क्या परीक्षण विचारों द्वारा संचालित डिजाइन है? यदि ऐसा है, तो परीक्षण ने विकास को बढ़ावा दिया। जो होने वाला है।

लेखन परीक्षण पहले पूरी तरह से आश्वस्त करते हैं कि परीक्षण ने विकास को बढ़ावा दिया। और यह refactoring सीमित करने के लिए जाता है।

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

Answer 3

यदि आप बाद में परीक्षण लिखते हैं, तो क्या वे वास्तव में विकास/डिजाइन चलाते हैं? मैं ऐसा नहीं सोचूंगा।

स्टीवन रॉबिन्स के उत्तर पर विस्तार करने के लिए: यदि आपका परीक्षण इसे पार करने से पहले विफल नहीं होता है, तो आपको कैसे पता चलेगा कि यह सही चीज़ का परीक्षण कर रहा है?

Answer 4

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

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

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

Answer 5

मैं 2000 के बाद से TDD (ठीक से) कर रहा हूँ वहाँ कई अच्छे अंक है कि दूसरों का उल्लेख किया है रहे हैं, लेकिन एक बात यह है कि बहुत महत्वपूर्ण और अन्य विवरण से याद आ रही है:

TDD आप बनाता है सरल कोड लिखें!

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

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