आप टीडीडी को कितनी दूर लागू कर सकते हैं?

Question

मुझे टीडीडी का लाभ दिखाई देता है, और मैं सीखने की कोशिश कर रहा हूं कि मेरे सिर को इसके चारों ओर कैसे लपेटें। मैं डीडीडी के बारे में और भी पढ़ रहा हूं और दोनों को अपनी सॉफ्टवेयर परियोजनाओं में आवेदन करना शुरू करना चाहता हूं।

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

पुस्तकों में से एक में

उदाहरण के लिए, ASP.NET 3.5 सामाजिक नेटवर्किंग, पूरे दूसरे अध्याय एक लॉगिंग आवरण वर्ग, एक ईमेल आवरण वर्ग, कैश और सत्र आवरण वर्गों (और उनके संबद्ध इंटरफेस) सभी को छुए बिना विकसित करता है एक इकाई परीक्षण पर। एक अन्य पुस्तक, सी # के साथ .NET डोमेन संचालित डिजाइन: समस्या, डिज़ाइन, समाधान समान है, और "असली" कोड को छूने से पहले बेस क्लास और रिपोजिटरी फ्रेमवर्क कोड बनाता है।

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

क्या यह टीडीडी लगाने का एक स्वीकार्य तरीका है?

Answer 1

यह संभवतः आपके प्रोजेक्ट को बनाने की योजना बनाने के बारे में अन्य कारकों पर निर्भर करता है।

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

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

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

Answer 2

मैं यहां कोई विशेषज्ञ नहीं हूं।

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

Answer 3

मैं another question में कुछ समय पर इसमें गया। असल में, टीडीडी और मैक्स और सभी चीजों का उपयोग करने का मुद्दा अधिक आत्मविश्वास विकसित करना है।

Answer 4

टीडीडी सीखते समय, सबकुछ लागू करें। इसके बाद, आपको जो चाहिए उसे लागू करें।

Answer 5

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

कोई होशियार के शब्दों में मैं से:

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

-uncle बॉब मार्टिन के माध्यम से: http://www.infoq.com/news/2009/02/spolsky-vs-uncle-bob

Answer 6

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

Answer 7

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

Answer 8

यदि आप कुछ कोड का परीक्षण करते हैं, और अन्य कोड का परीक्षण नहीं करते हैं, तो कौन से कोड में बग होगा?

संकेत: यह अनचाहे कोड है।