टीडीडी

Question

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

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

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

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

एक संबंधित प्रश्न: क्या तालिका से यादृच्छिक संख्या चुनना बुरा विचार था? किसी त्रुटि के मामले में, मैं इस रन द्वारा उपयोग किए जाने वाले यादृच्छिक-बीज को प्रदर्शित करूंगा, ताकि मैं बग को पुन: उत्पन्न कर सकूं।

Answer 1

"मुझे यह धारणा थी कि मुझे कुछ मिनटों से अधिक समय तक कोड नहीं करना चाहिए, जब तक परीक्षण फिर से हरे रंग की न हो। मैंने यहां क्या गलत किया?"

वेस्टफल एक बिंदु तक सही है।

कुछ कार्यक्षमता सरल शुरू होती है और इसका परीक्षण किया जा सकता है और बस कोड किया जा सकता है।

कुछ कार्यक्षमता सरल शुरू नहीं होती है। हासिल करना मुश्किल है। ईडब्ल्यूडी का कहना है कि सादगी का मूल्य नहीं है क्योंकि इसे हासिल करना बहुत मुश्किल है।

यदि आपके फ़ंक्शन बॉडी को लिखना मुश्किल है, तो यह आसान नहीं है। इसका मतलब है कि आपको इसे सरल करने के लिए इसे अधिक कठिन बनाना है।

अंततः सादगी प्राप्त करने के बाद, आप भी एक पुस्तक लिख सकते हैं जो यह दिखाता है कि यह कितना आसान है।

जब तक आप सादगी प्राप्त नहीं करते हैं, तो चीजों को लिखने में काफी समय लगेगा।

"क्या टेबल से यादृच्छिक संख्या चुनना बुरा विचार था?"

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

एक पंक्ति का चयन न करें - यादृच्छिक रूप से या अन्यथा, सभी पंक्तियों का चयन करें।

Answer 2

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

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

Answer 3

आपको बच्चे के चरणों का उपयोग करके टीडीडी करना चाहिए। उन परीक्षणों के बारे में सोचने का प्रयास करें जिन्हें कम कोड लिखा जाना चाहिए। फिर कोड लिखें। फिर एक और परीक्षण लिखें, और इसी तरह।

अपनी समस्या को छोटी समस्याओं में तोड़ने का प्रयास करें (आपने शायद अपना कोड पूरा करने के लिए कुछ अन्य तरीकों का उपयोग किया है)। आप इन छोटी विधियों को टीडीडी कर सकते हैं।

--EDIT - टिप्पणी

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

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

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

Answer 4

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

वर्ग एक { सार्वजनिक doLotsOfStuff() // doTask1..n निजी doTask1 (कॉल) निजी doTask2() निजी doTask3() }

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

वर्ग एक { सार्वजनिक doLotsOfStuff() // doTask1..n सार्वजनिक doTask1 (कॉल) सार्वजनिक doTask2() सार्वजनिक doTask3() }

: शायद अपने संभावित समाधान इस तरह पुनर्निर्मित किया जा सकता है जबकि आपकी निजी विधियां कार्यान्वयन विस्तार हो सकती हैं जो अलगाव में उनका परीक्षण करने से बचने का कारण नहीं है। कई समस्याओं की तरह ही विभाजन और विजय दृष्टिकोण यहां प्रभावशाली साबित होगा। वास्तविक सवाल यह है कि आकार क्या कार्यक्षमता का एक उपयुक्त टेस्टेबल और रखरखाव हिस्सा है? केवल आप समस्या के बारे में अपने ज्ञान और कार्य के लिए अपनी क्षमताओं को लागू करने के अपने निर्णय के आधार पर इसका उत्तर दे सकते हैं।

Answer 5

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

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

छोटे परीक्षण सीधे विधियों पर छोटे यूनिट परीक्षणों के साथ अपनी कार्यक्षमता का निर्माण करने के बाद सिस्टम परीक्षण संभवतः किया जाना चाहिए।

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

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

Answer 6

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

अपने प्रश्न का उत्तर देने के लिए, मुझे लगता है कि हाँ, कुछ मामलों में, यह "हरा नहीं होने तक" 2 मिनट नहीं है। उन मामलों में, मुझे लगता है कि परीक्षणों के लिए हरे रंग के लिए लंबे समय तक लगना ठीक है। लेकिन अधिकांश स्थितियों "हरे रंग की जाने तक 2 मिनट" स्थितियां हैं। आपके मामले में (मुझे द्विपदीय वितरण के बारे में पता नहीं है), आपने लिखा है कि आपके पास 3 तर्क हैं, एन, के और पी। यदि आप के और पी स्थिर रखते हैं, तो क्या आपका कार्य लागू करने के लिए कोई आसान तरीका है? यदि हां, तो आपको उन परीक्षणों को शुरू करके शुरू करना चाहिए जो हमेशा निरंतर के और पी होते हैं। जब आपके परीक्षण पास होते हैं, तो के लिए एक नया मान प्रस्तुत करें, और फिर पी के लिए।

Answer 7

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

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

जैसे ही आप अधिक परीक्षण तकनीकों को सीखते हैं, आपको लाल/हरे चक्र को कम करने वाले विभिन्न दृष्टिकोण मिल सकते हैं। इस बीच, इसके बारे में बुरा मत मानो। इसका अंत करने का साधन है, न कि अंत में।