TDD, नए परीक्षण जबकि पुराने अभी तक लागू नहीं किए गए हैं


13

मैं परीक्षण-संचालित विकास के साथ प्रयोग कर रहा हूं, और मैंने पाया कि मैं अक्सर निम्नलिखित स्थिति में आता हूं:

  1. मैं कुछ कार्यक्षमता X के लिए परीक्षण लिखता हूं। वे परीक्षण विफल हो जाते हैं।
  2. एक्स को लागू करने की कोशिश करते समय, मैं देखता हूं कि मुझे अपने कोड की निचली परत में कुछ सुविधा वाई को लागू करने की आवश्यकता है। इसलिए...
  3. मैं Y के लिए परीक्षण लिखता हूं। अब X और Y के लिए दोनों परीक्षण विफल हो जाते हैं।

एक बार जब मैं एक ही समय में काम कर रहा था, तो कोड की विभिन्न परतों में 4 विशेषताएं थीं, और मैं अपना ध्यान इस पर खो रहा था कि मैं वास्तव में क्या कर रहा हूं (एक ही समय में कई परीक्षण विफल हो रहे हैं)।

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

ऐसे मामलों में मुझे क्या करना चाहिए? क्या TDD की कोई सिफारिश है?

जवाबों:


9

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


मेरे परीक्षणों में आमतौर पर इस बारे में ज्ञान नहीं होता है कि आंतरिक रूप से क्या करना चाहिए (फोन करने के लिए निम्न-स्तरीय एपीआई क्या है)। क्या मुझे परीक्षण कोड में जो कुछ भी चाहिए, उसका मजाक उड़ाने के लिए परीक्षणों को समायोजित करना चाहिए?
लियोरी

2
इसी तरह, आपके परीक्षित वर्ग को यह ध्यान नहीं देना चाहिए कि 'निचली परतें' क्या करती हैं। वास्तविक कक्षाओं / वस्तुओं के स्थान पर मोक्स / स्टब्स का उपयोग करें। इसके लिए डिज़ाइन में थोड़ी अधिक मेहनत की आवश्यकता हो सकती है, लेकिन कोड में परिणाम कम युग्मित और पुन: उपयोग में आसान होता है।
15

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

@ माइक ब्राउन, हां, मैं करता हूं। मुझे पता है कि मैं नकली वस्तुएं बना सकता हूं। लेकिन फिर फीचर के लिए मेरे परीक्षण में Xमुझे यह जानना होगा कि Xमुझे मॉक की निर्भरता के किस हिस्से की आवश्यकता है। मुझे लगता है कि यह कार्यान्वयन विवरण का हिस्सा है, जो परीक्षणों का हिस्सा नहीं होना चाहिए - अन्यथा मुझे कार्यान्वयन को रद्द करते समय परीक्षणों को बदलने की आवश्यकता हो सकती है। क्या मुझे उसकी चिंता करनी चाहिए?
लियोरी

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

4

स्टब्स और मॉक्स का उपयोग उस कार्यक्षमता को अनुकरण करने के लिए किया जा सकता है जिसे अभी तक संशोधित / कार्यान्वित नहीं किया जा रहा है। वे उन निर्भरताओं को हल करने में भी आपकी मदद कर सकते हैं जो इस तरह की 'चेन रिएक्शन' का कारण बनती हैं।

दूसरी ओर, हो सकता है कि बहुत ही अगले बदलाव को चलाने वाला केवल एक (असफल) परीक्षण सबसे अच्छा तरीका हो।

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

इस तरह आप अपना ध्यान केवल अगले बदलाव पर रख सकते हैं, जो आप चाहते हैं, मुझे लगता है।


हा, मैंने अपने आईडीई के अंदर एक टेस्ट रन के दौरान एक परीक्षण को बंद करने के लिए एक सुविधा की तलाश की, और एक नहीं मिला। अब मैंने पाया कि अजगर का unittestपहले से ही परीक्षण लंघन है। यह मेरे लिए पर्याप्त हो सकता है।
लियोरी

हम Google परीक्षण C ++ फ्रेमवर्क का उपयोग करते हैं - और इसमें परीक्षण अक्षम करने का विकल्प होता है। अक्षम परीक्षणों को निष्पादित नहीं किया जाता है बल्कि संकलित किया जाता है - जिस क्षण आपको उनकी आवश्यकता होती है - वे वहाँ चलाने के लिए तैयार होते हैं (इसके अलावा आप अक्षम परीक्षणों का 'बल निष्पादन' कर सकते हैं - इस प्रकार का 'रन-टाइम इनेबल') - उत्कृष्ट विशेषता ...
ratkok

3

रुकें

ऐसा लगता है कि यहां दो अलग-अलग मुद्दे हो सकते हैं:

  1. आप कुछ कहानियों और परीक्षण परिदृश्यों को भूल गए, और जब तक आप एक विशेष परीक्षण परिदृश्य, और / या पर काम करना शुरू नहीं करते, तब तक उन्हें खोज नहीं किया

  2. आप वास्तव में इकाई परीक्षण कर रहे हैं, न कि TDD सुविधा परीक्षण

# 1 के लिए, बंद करो , वापस जाओ, और कहानियों और परीक्षण परिदृश्यों को अपडेट करें, फिर एक अलग परिदृश्य के साथ शुरू करें।

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


मुझे वास्तव में आपका उत्तर पसंद है, यह समझाने का एक बेहतर काम करता है कि वास्तव में क्या चल रहा है।
maple_shaft

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

@maple_shaft: जिस समय को आप फिर से इकट्ठा करने के लिए रोकते हैं, वह केवल कुछ घंटों का हो सकता है - जब तक कि आपकी प्रक्रिया नहीं होती है, आधार से रास्ता, जिस स्थिति में इसे वापस पटरी पर लाने के लिए कुछ दिनों के लिए रुकना इसे और अधिक संभव बना देगा। परियोजना सफल होगी। गलत ट्रैक के आगे पूरी भाप जाने का कोई मतलब नहीं है!
स्टीवन ए। लोव

0

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

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

प्रोटोटाइप

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

यदि प्रोटोटाइप को इतना शामिल करना पड़ता है कि यह एप्लिकेशन बन जाता है तो मैं आपसे आग्रह करता हूं कि आप आलसी काम न करें और तथ्य के बाद अपने प्रोटोटाइप के लिए यूनिट टेस्ट बनाएं।

आपको उस बिंदु पर निचले स्तर के एपीआई के बारे में अधिक जानकारी होनी चाहिए और अपने उच्च स्तर के घटकों में निचले स्तर के एपीआई का सफलतापूर्वक मजाक बनाने में सक्षम होना चाहिए।


इसलिए आप वास्तव में अनौपचारिक (= कुछ औपचारिक पद्धति से नहीं) तरीके से कुछ खोजपूर्ण कोडिंग करके योजना चरण के लिए अधिक जानकारी प्राप्त करने का सुझाव दे रहे हैं। और फिर मान लें कि यह वास्तविक कोड की योजना के लिए पर्याप्त जानकारी देगा। क्या मैं सही हू?
लियोरी

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

"अनौपचारिक तरीके" से मेरा मतलब यह नहीं था कि प्रोटोटाइप के लिए समय का हिसाब नहीं होना चाहिए, लेकिन जब आप प्रोटोटाइप करते हैं, तो आप TDD या किसी अन्य कोड कार्यप्रणाली का पालन नहीं करते हैं।
लियोरी

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

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

0

यह निर्भर करता है कि टीडीडी करते समय आपके लेखन में किस तरह के परीक्षण हैं।

क्लासिक मॉडल इकाई परीक्षणों को लिखना और कोड के अन्य "इकाइयों" से परीक्षण को डिकूप करने के लिए मोक्स या स्टब्स का उपयोग करना है।

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

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