यूनिट टेस्ट लिखने से पहले कोड लिखने के नुकसान क्या हैं?

Question

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

जैसा कि मैंने परीक्षण शुरू करने और फिर कोडिंग पर जाने के लिए बहुत सी सिफारिशें देखी हैं, अगर मैं इसे दूसरे तरीके से करता हूं तो क्या नुकसान हैं - कोड लिखना और फिर इकाई परीक्षण?

Comments

+1 यह पूछने के लिए कि इसे गले लगाने से पहले एक निश्चित अभ्यास एक "सर्वोत्तम अभ्यास" क्यों है

— टेलरऑटवेल

Answer 1

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

कोड के बाद विकसित की गई आवश्यकताएँ (परीक्षण), कोड के आधार पर आपको उस तरह की निश्चितता से वंचित कर देती हैं, जो कि विश्वास है।

Comments

+1 - उत्कृष्ट बिंदु और बिंदु लिया गया! आपकी राय के लिए धन्यवाद!

— k25

टेस्ट! = आवश्यकताएँ। परीक्षण और कोड दोनों को आवश्यकताओं से प्राप्त किया जाना चाहिए ।

— बार्ट वैन इनगेन शनाउ

@ बर्ट वैन इनगेन शेनौ: टीडीडी की ताकत ठीक है कि परीक्षण आवश्यकताएं हैं। इसके अलावा, वे निष्पादन योग्य आवश्यकताएं हैं।

— मौविसीयल

@ बर्ट: यूनिट परीक्षण अक्सर (उच्च स्तर) ग्राहकों की आवश्यकताओं के लिए विस्तृत होते हैं, लेकिन यह विचार निश्चित रूप से धारण करता है, खासकर अगर हम उच्च स्तर के परीक्षण जैसे कि स्वचालित स्वीकृति परीक्षण पर विचार करते हैं, जो एक बार लिखा जाता है, तो निश्चित आवश्यकताएं होनी चाहिए। यही "चुस्त स्वीकृति परीक्षण" का सार है।

— मार्टिन विकमैन

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

— मौविसील

Answer 2

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

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

Comments

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

— k25

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

— कार्ल मैनस्टर

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

— k25

@ k25: मुद्दा यह है कि यदि आपका टेस्ट केस पास हो जाता है, तब भी आपको पता नहीं चलता कि कोड सही है या नहीं। परीक्षण का मामला गलत हो सकता है।

— आनन।

@Anon। - हां आप सही हैं, मैं इस मामले को भी ध्यान में रखूंगा।

— k25

Answer 3

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

बात यह है कि मैंने अन्य सामानों की अधिकता सीखी है जो टीडीडी के साथ कसकर बुनना है। इससे कोई फर्क नहीं पड़ता कि आप पहले परीक्षण करते हैं: सॉफ्टवेयर डिजाइन के बारे में क्या सोच है ।

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

व्यक्तिगत रूप से मैंने खुद को ठोस सिद्धांतों को सीखा, बिना यह जाने कि ऐसी कोई बात लिखी हुई थी। ऐसा इसलिए है क्योंकि लेखन इकाई परीक्षणों ने मुझे कक्षाओं को फिर से लिखने के लिए मजबूर किया है ताकि वे परीक्षण करने के लिए अत्यधिक जटिल न बनें। यह इस तरह की चीजों के लिए नेतृत्व किया:

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

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

Comments

जब आप सॉफ़्टवेयर डिज़ाइन के बारे में सोचते हैं, तो SOLID के लिए +1 स्वाभाविक रूप से आपके लिए होता है।

— ओशोडो

+1 (वास्तव में मैं +10 देना चाहता था लेकिन मैं नहीं कर सकता)। वास्तव में मेरे विचार - आप अंकों की सूची बहुत अच्छे थे। यही एक कारण है कि मैंने यह सवाल पूछा। मैंने महसूस किया कि जब मैंने कोड लिखा था तब मैंने यूनिट टेस्ट लिखना शुरू कर दिया था। लेकिन मैं दोनों पक्षों के फायदे / नुकसान देखना चाहता था, आपकी राय के लिए धन्यवाद!

— k25

Answer 4

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

Answer 5

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

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

Comments

पहले अंक के लिए +1। लेकिन, मापदंडों के स्तर पर नहीं, क्या होगा अगर डिजाइन दूसरों के साथ चर्चा की गई और स्वीकार किया गया?

— k25

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

— आनन

यकीन है, संकेत के लिए धन्यवाद, मैं निश्चित रूप से उन में दिखेगा ...

— k25

Answer 6

जैसा कि मैंने परीक्षण शुरू करने और फिर कोडिंग पर जाने के लिए बहुत सी सिफारिशें देखीं,

इसके लिए एक वास्तविक अच्छा कारण है।

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

यदि आप कहते हैं कि "पहले परीक्षण लिखें", तो लोग कम से कम सही काम करने की कोशिश कर सकते हैं।

यदि मैं इसे दूसरे तरीके से करता हूं तो क्या नुकसान हैं - कोड लिखना और फिर यूनिट परीक्षण?

आमतौर पर, एक घटिया परीक्षण और एक डिजाइन जिसे परीक्षण योग्य होने के लिए फिर से काम करना पड़ता है।

हालाँकि, यह केवल एक "आमतौर पर" है। कुछ लोग समानांतर में डिजाइन और परीक्षण विकसित करते हैं। कुछ लोग परीक्षण योग्य कोड डालते हैं और बिना किसी रिपोर्ट के परीक्षण लिखते हैं।

"टेस्ट फर्स्ट" नियम विशेष रूप से उन लोगों को सिखाने और निर्देश देने के लिए है, जिनके पास कोई सुराग नहीं है।

इसी तरह से, हमें हमेशा सड़क पार करने से पहले "दोनों तरीके" देखने के लिए कहा जाता है। हालाँकि, हम वास्तव में नहीं है। और इससे कोई फर्क नहीं पड़ता। मैं राइट-हैंड ड्राइव वाले देश में रहता हूं और क्रॉस करने के लिए शुरू होने पर मुझे केवल बाईं ओर देखना होगा।

जब मैं बाएं हाथ के ड्राइव देश में जाता हूं, तो बाईं ओर देखने से मुझे मौत मिल सकती है।

नियमों को एक कारण के लिए बहुत दृढ़ता से कहा गया है।

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

Answer 7

परीक्षण लिखने की बात यह है कि यह आपके बारे में सोचता है

• कोड का परीक्षण कैसे करें
• इंटरफ़ेस कोड को परीक्षण करने योग्य होना चाहिए

यदि आप कुछ सरल कर रहे हैं, तो यह संभवत: कोई फर्क नहीं पड़ता कि आप कौन सा पहले लिखते हैं (हालांकि परीक्षण-पहली आदत पर खेती करना अच्छा है) क्योंकि परीक्षण सरल होगा और इंटरफ़ेस स्पष्ट होगा

लेकिन TDD स्वीकार्यता परीक्षण में, न केवल इकाई परीक्षण में, और फिर इंटरफ़ेस गैर-तुच्छ हो जाता है।

Answer 8

सबसे पहले यदि आप अपने परीक्षण पहले नहीं लिखते हैं तो आप टेस्ट ड्रिवेन डेवलपमेंट (टीडीडी) नहीं कर रहे हैं। जब तक आप इसे कई बार अभ्यास नहीं करते तब तक लाभ कई और अक्सर विश्वास करना मुश्किल होता है। पारंपरिक विकास पर टीडीडी करने से मुझे जो लाभ प्राप्त हुए हैं, वे यहां हैं:

1. परीक्षणों का एक सुरक्षा जाल - आपको अनजाने में कुछ तोड़ने के डर के बिना बड़े बदलाव करने की अनुमति देता है
2. ऑर्गेनिक डिज़ाइन - मेरे द्वारा डिज़ाइन किया गया डिज़ाइन आमतौर पर अलग होता है कि डिज़ाइन जो मैंने स्क्रैच से किया होता है और यह हमेशा बेहतर होता है
3. उत्पादकता - छोटे लक्ष्यों के लिए काम करना (इस एक परीक्षा को पास करना) और इसे बनाना (सभी परीक्षण पास) मेरे लिए वास्तव में अच्छी तरह से काम करते हैं और मुझे प्रेरित करते हैं। एक जोड़ी में जोड़ें और मेरी उत्पादकता नई ऊँचाइयों तक पहुँचती है।

पुस्तकें: बेक, के। टेस्ट-ड्रिवेन डेवलपमेंट बाय उदाहरण

अच्छा उदाहरण: http://jamesshore.com/Blog/Lets-Play/

Comments

+1 - अच्छे अंक (विशेषकर 1) और लिंक के लिए धन्यवाद!

— k25

Answer 9

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

पहले कोड लिखना और उसके बाद परीक्षण का प्रश्न खुल जाता है कि क्या परीक्षण एक ईमानदार असफल दिखाएगा।

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