टीडीडी करने वाले लोग प्रमुख रिफैक्टरिंग करते समय काम का नुकसान कैसे करते हैं


37

कुछ समय से मैं अपने कोड के लिए यूनिट टेस्ट लिखना सीखने की कोशिश कर रहा हूं।

शुरू में मैंने सही TDD करना शुरू किया, जहाँ मैं कोई भी कोड तब तक नहीं लिखता था जब तक कि मैं पहले असफल परीक्षा नहीं लिखता।

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

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

मैं यह सोचने में मदद नहीं कर सकता कि मैंने उन परीक्षणों को लिखने के 3 या 4 दिनों के प्रयास को बर्बाद कर दिया है जब मैं कोड को अवधारणा के प्रमाण के लिए एक साथ रख सकता था और फिर अपने दृष्टिकोण से खुश होने के बाद परीक्षणों को लिखा।

टीडीडी का अभ्यास करने वाले लोग ऐसी परिस्थितियों को ठीक से कैसे संभालते हैं? क्या कुछ मामलों में नियमों को झुकने के लिए एक मामला है या क्या आप हमेशा परीक्षणों को सबसे पहले लिखते हैं, तब भी जब कोड बेकार हो सकता है?


6
पूर्णता तब प्राप्त होती है, जब जोड़ने के लिए और कुछ नहीं होता है, लेकिन जब लेने के लिए कुछ नहीं बचता है। - एंटोनी डी सेंट-
एक्सुपरी

12
यह कैसे संभव है कि आपके सभी परीक्षण गलत हैं? कृपया बताएं कि आपके द्वारा लिखे गए हर एक परीक्षण को लागू करने में बदलाव कैसे अमान्य है।
एसएलटी

6
@ S.Lott: परीक्षण गलत नहीं थे, वे अब प्रासंगिक नहीं थे। मान लें कि आप अभाज्य संख्याओं का उपयोग करके किसी समस्या का हिस्सा हल कर रहे हैं, इसलिए आप अभाज्य संख्याएँ उत्पन्न करने के लिए एक वर्ग लिखते हैं और यह सुनिश्चित करने के लिए उस कक्षा के लिए परीक्षण लिखते हैं कि यह काम कर रहा है। अब आप अपनी समस्या के लिए एक और पूरी तरह से अलग समाधान ढूंढते हैं जो किसी भी तरह से primes को शामिल नहीं करता है। वह वर्ग और यह परीक्षण अब बेमानी है। यह केवल 10 वर्गों के साथ केवल एक ही नहीं मेरी स्थिति थी।
GazTheDestroyer

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

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

जवाबों:


33

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

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

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


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

3
"मैंने परीक्षण लिखने पर काम किया जैसा कि मैंने किया था कि सभी टीडीडी साहित्य में बहुत तनाव है"। आपको शायद अपने विचार के स्रोत के साथ प्रश्न को अपडेट करना चाहिए कि सभी परीक्षण किसी भी कोड से पहले लिखे जाने चाहिए ।
S.Lott

1
मेरे पास ऐसा कोई विचार नहीं है और मुझे यकीन नहीं है कि टिप्पणी से आपको कैसा लगा।
GazTheDestroyer

1
मैं एक उत्तर लिखने जा रहा था, लेकिन तुम्हारी जगह अपवित्र हो गया। हां, एक लाख बार हां: अगर आपको नहीं पता कि आपका आर्किटेक्चर अभी तक कैसा दिखता है, तो
रॉबर्ट हार्वे

1
@ArrenP, निश्चित रूप से ऐसे लोग हैं जो सोचते हैं कि TDD वन ट्रू वे (कुछ भी धर्म में बदल दिया जा सकता है अगर आप पर्याप्त प्रयास करें। ;-) मैं हालांकि व्यावहारिक होना पसंद करता हूं। मेरे लिए मेरे टूलबॉक्स में टीडीडी एक उपकरण है, और मैं इसका उपयोग केवल तभी करता हूं जब यह मदद करता है, समस्याओं को हल करने के बजाय।
Péter Török

8

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


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

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

1
@ किलियन, पुनः "टीडीडी का वादा है कि यह आपको समान लक्ष्यों तक तेज़ी से पहुँचाता है" - आप यहाँ किस लक्ष्य का उल्लेख कर रहे हैं? यह बहुत स्पष्ट है कि उत्पादन कोड के साथ ही यूनिट परीक्षण लिखना आपको कोड को मंथन करने की तुलना में शुरू में धीमा बनाता है । मैं कहूंगा कि बेहतर गुणवत्ता और कम रखरखाव लागत के कारण, TDD केवल लंबी अवधि में वापस भुगतान करने जा रहा है।
Péter Török

@ PéterTörök - ऐसे लोग हैं जो TDD पर जोर देते हैं, उनकी कभी भी कोई कीमत नहीं होती क्योंकि यह आपके द्वारा कोड लिखे जाने के समय तक ही भुगतान करता है। यह निश्चित रूप से मेरे लिए नहीं है, लेकिन किलियन इसे खुद के लिए मानता है।
Psr

ठीक है ... यदि आप ऐसा नहीं मानते हैं, तो वास्तव में यदि आप यह नहीं मानते हैं कि टीडीडी के पास लागत के बजाय पर्याप्त भुगतान है , तो ऐसा करने का कोई मतलब नहीं है, क्या यह है? न केवल बहुत विशिष्ट स्थिति में जिसे गज़ ने वर्णित किया, बल्कि बिल्कुल भी नहीं । मुझे डर है कि मैंने अब इस धागे को पूरी तरह से विषय से हटा दिया है :(
किलन फ़ॉथ

6

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

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

आपकी समस्या शायद डिजाइन की हो और जरूरी नहीं कि कोड की हो। लेकिन अधिक विवरण के बिना, यह कहना मुश्किल है।


यह केवल परिधीय है, लेकिन पीडीई क्या है?
एक CVn

1
@ माइकलकॉर्जिंग मुझे लगता है कि यह आंशिक अंतर समीकरण है
फोर्स्ड

2
क्या ब्रूक्स ने अपने 2 संस्करण में उस बयान को वापस नहीं लिया?
साइमन

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

5

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

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


1
मुझे नहीं लगता कि मैंने खुद को बहुत अच्छे से समझाया होगा। मैं पुनरावृत्तियाँ परीक्षण लिखता हूँ। इस तरह मैंने कोड के लिए कई सौ परीक्षणों को समाप्त कर दिया जो अचानक निरर्थक हो गए।
GazTheDestroyer

1
जैसा कि ऊपर - मुझे लगता है कि इसे " कोड के लिए परीक्षण" के बजाय "परीक्षण और कोड" के रूप में सोचा जाना चाहिए
मर्फ़

1
+1: "आपको सभी परीक्षणों को एक बार में लिखने की कोशिश नहीं करनी चाहिए,"
9'12 को S.Lott

4

मुझे लगता है कि आपने इसे खुद कहा था: आप अपने सभी यूनिट परीक्षणों को लिखने से पहले अपने दृष्टिकोण के बारे में निश्चित नहीं थे।

जिस चीज़ की मैंने वास्तविक-जीवन की TDD परियोजनाओं की तुलना की है, उसके साथ मैंने काम किया है (ऐसा नहीं है कि वास्तव में कई, केवल 3 साल के काम को कवर करते हुए) जो मैंने सैद्धांतिक रूप से सीखा था, वह यह है कि स्वचालित परीक्षण! = इकाई परीक्षण (बेशक बिना पारस्परिक रूप से) विशेष)।

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

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

शायद यह ऐसा करने का मेरा निजी तरीका है। मेरे पास खरोंच से तय करने के लिए पर्याप्त अनुभव नहीं है कि मेरी परियोजना में क्या पैटर्न या संरचना होगी, इसलिए वास्तव में मैं शुरुआत से 100s UTs लिखने में अपना समय बर्बाद नहीं करूंगा ...

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


3
अच्छी तरह से कहा - यह TDD है, UTDD नहीं
स्टीवन ए। लोवे

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

4
टीडीडी का अभ्यास करने वाले लोग ऐसी परिस्थितियों को ठीक से कैसे संभालते हैं?
  1. कब कोड के लिए प्रोटोटाइप बनाम कब पर विचार करके
  2. यह महसूस करके कि इकाई परीक्षण टीडीडी के समान नहीं है
  3. TDD परीक्षण एक सुविधा / कहानी को सत्यापित करने के लिए, एक कार्यात्मक इकाई द्वारा नहीं

परीक्षण-संचालित विकास के साथ इकाई परीक्षण का टकराव बहुत पीड़ा और शोक का स्रोत है। तो चलिए एक बार फिर इसकी समीक्षा करते हैं:

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

सारांश में: इकाई परीक्षण में एक कार्यान्वयन फोकस है, टीडीडी में आवश्यकताओं पर ध्यान केंद्रित किया गया है। ये एक ही चीज नहीं हैं।


"टीडीडी के पास एक आवश्यकताओं पर ध्यान केंद्रित है" मैं इससे पूरी तरह असहमत हूं। परीक्षण TDD में अपने लिखने हैं इकाई परीक्षण। वे कर प्रत्येक कार्य / विधि की पुष्टि करें। TDD में कोड कवरेज पर जोर होता है और उन परीक्षणों की परवाह करता है जो जल्दी से निष्पादित होते हैं (और वे बेहतर करते हैं, क्योंकि आप हर 30 सेकंड या इतने पर परीक्षण चलाते हैं)। शायद आप ATDD या BDD सोच रहे थे?
गुरिल्ला ०३

1
@ ian31: UT और TDD संगम का सही उदाहरण। असहमत होना चाहिए, और आपको कुछ स्रोत सामग्री en.wikipedia.org/wiki/Test-driven_development का उल्लेख करना चाहिए - परीक्षणों का उद्देश्य कोड आवश्यकताओं को परिभाषित करना है । BDD महान है। ATDD के बारे में कभी नहीं सुना, लेकिन एक नज़र में ऐसा लगता है कि मैं TDD स्केलिंग कैसे लागू करता हूँ ।
स्टीवन ए लोव

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

इसके अलावा, आपके द्वारा बताए गए विकिपीडिया लेख से: "परीक्षण-संचालित विकास की उन्नत प्रथाओं में एटीडीडी हो सकती है जहां ग्राहक द्वारा निर्दिष्ट मानदंड स्वीकृति परीक्षणों में स्वचालित होते हैं, जो तब पारंपरिक इकाई परीक्षण-संचालित विकास (UTDD) प्रक्रिया को चलाते हैं।" ...] ATDD के साथ, विकास टीम के पास अब संतुष्ट करने के लिए एक विशिष्ट लक्ष्य है, स्वीकृति परीक्षण, जो उन्हें लगातार इस बात पर केंद्रित रखता है कि ग्राहक वास्तव में उस उपयोगकर्ता कहानी से क्या चाहता है। " ऐसा लगता है कि एटीडीडी मुख्य रूप से आवश्यकताओं पर केंद्रित है, न कि टीडीडी (या यूटीडीडी के रूप में वे इसे डालते हैं)।
guillaume31

@ ian31: ओपी के सवाल 'कई सौ यूनिट परीक्षण फेंकने' के बारे में बड़े पैमाने पर भ्रम की स्थिति का संकेत मिलता है। आप चाहें तो शेड बनाने के लिए टीडीडी का उपयोग कर सकते हैं। : D
स्टीवन ए। लोव

3

टेस्ट-संचालित विकास आपके विकास को चलाने के लिए है । आपके द्वारा लिखे गए परीक्षण आपको उस कोड की शुद्धता का पता लगाने में मदद करते हैं जो आप वर्तमान में लिख रहे हैं और पहली पंक्ति से विकास की गति बढ़ाते हैं।

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

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


2

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

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

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

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


1

मुझे इस बात पर यकीन नहीं है कि 3 दिनों के बाद आपका दृष्टिकोण त्रुटिपूर्ण क्यों हो गया। आपकी वास्तुकला में अनिश्चितताओं के आधार पर, आप अपनी परीक्षण रणनीति को बदलने पर विचार कर सकते हैं:

  • यदि आप प्रदर्शन के बारे में अनिश्चित हैं, तो आप कुछ एकीकरण परीक्षणों के साथ शुरू कर सकते हैं जो प्रदर्शन को मुखर करते हैं?

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


0

मेरे लिए इकाई परीक्षण "वास्तविक" उपयोग के तहत इंटरफ़ेस डालने के लिए एक अवसर के रूप में भी हैं (ठीक है, जैसा कि इकाई परीक्षण चलते हैं असली!)।

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

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

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


0

रचनात्मक डेवलपर्स सर्कस में आपका स्वागत है


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







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

ऐसा प्रतीत होता है:
- आपने सभी नियमों का सम्मान करते हुए एक कोड लिखा है
- आपको एक अनुभव, काम का एक नया तरीका,
- आपके दिमाग में कुछ बदलाव आता है, आप नए कॉन्फ़िगरेशन से कभी नहीं डरेंगे।

और अब, यदि आप एक यूएमएल को ऊपर की तरह देख रहे हैं, तो आप
"बॉस, मैं इसके लिए टीडीडी द्वारा शुरू करने में सक्षम हो जाएगा ..."
यह एक और नई बात है?
"बॉस, मैं कुछ तरीका तय करने से पहले कोशिश करूँगा कि मैं कोड कैसे बनाऊँ .."

PARIS
क्लाउड से सबसे अच्छा संबंध है

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.