यूनिट परीक्षण और परीक्षण संचालित विकास के बीच अंतर

64

विवरण पढ़ने से, मैं समझता हूं कि फ़ंक्शन लिखने से पहले और उसके बाद किए गए यूनिट परीक्षण में टीडीडी परीक्षण किए जाते हैं।

क्या यह मुख्य अंतर है, या दो शब्दों की तुलना भी नहीं की जा सकती। शायद, यूनिट परीक्षण टीडीडी का एक एकीकृत हिस्सा है।

unit-testing tdd difference

— शमीम हाफिज
स्रोत

104

यूनिट टेस्टिंग को संदर्भित करता है क्या आप परीक्षण कर रहे हैं, TDD करने के लिए जब आप परीक्षण कर रहे हैं।

दो ऑर्थोगोनल हैं।

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

अपना कोड लिखने से पहले या जब आप अपना कोड लिखेंगे, तब आप अपना कोड लिखने से पहले यूनिट टेस्ट लिख सकते हैं।

TDD का अर्थ है (फिर से, स्पष्ट प्रकार) आपके परीक्षणों को आपके विकास (और आपके डिज़ाइन) को चलाने देता है। आप इकाई परीक्षण, कार्यात्मक परीक्षण और स्वीकृति परीक्षण के साथ कर सकते हैं। आमतौर पर, आप तीनों का उपयोग करते हैं।

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

— जोर्ग डब्ल्यू मित्तग
स्रोत

1

बहुत बढ़िया जवाब। जोड़ना होगा ... TDD है जब आप परीक्षणों को धक्का देने के लिए और अपने विकास के प्रयासों को खींचने के लिए सुविधाएँ ...

— मार्टिन

हालांकि वे ऑर्थोगोनल नहीं हैं। आप इकाई परीक्षणों के बिना TDD नहीं कर सकते।

— जाकबीस

1

@JacquesB, क्यों? हमारे परीक्षण वे नहीं हैं जिन्हें आप किसी भी परिभाषा के अनुसार इकाई परीक्षण कहते हैं, वे बुनियादी ढांचे और अन्य घटकों पर बहुत अधिक निर्भर करते हैं, लेकिन हमारे पास अभी भी पर्याप्त अवलोकन है कि हम - कम से कम कुछ हम - टीडीडी कर रहे हैं।

— एपीग्रामग्राम

3

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

— जोर्ग डब्ल्यू मित्तग

1

@ JörgWMittag आप इसे देखने के एक शुद्ध तरीके से सही हो सकते हैं, लेकिन आप यह भी जानते हैं कि TDD काला और सफेद नहीं है। टीडीडी के किसी भी समझदार उपयोग ने परीक्षणों को पूरी तरह से विकसित नहीं होने दिया, और निश्चित रूप से परीक्षण हमेशा यह तय नहीं करते हैं कि डिजाइन कैसा दिखता है (शायद इकाई परीक्षण आंशिक रूप से ऐसा कर सकते हैं, लेकिन उच्च अमूर्त स्तर पर परीक्षण नहीं)। रिफैक्टरिंग के बारे में क्या? जो टीडीडी का एक बहुत महत्वपूर्ण पहलू है। वास्तविक दुनिया में भी 'परीक्षण आपको बता रहा है सब कुछ अनदेखा करें' जैसी कोई चीज नहीं है। परिभाषा के अनुसार, यदि आप पहले परीक्षण लिखते हैं, तो आप 'TDD के कुछ रूप' का उपयोग करते हैं।

— निकोल

21

यूनिट टेस्टिंग टेस्ट ड्रिवेन डेवलपमेंट का एक घटक है

आप परीक्षण संचालित विकास किए बिना इकाई परीक्षण कर सकते हैं। हालाँकि आप इकाई परीक्षणों का उपयोग किए बिना संचालित विकास का परीक्षण नहीं कर सकते।

जब आप पारंपरिक इकाई परीक्षण करते हैं , तो आप अपना कोड लिखने के बाद परीक्षण लिखते हैं ।

टेस्ट संचालित विकास दृष्टिकोण कोड लिखने से पहले यूनिट टेस्ट लिखना है।

TDD (IMHO) के सबसे दिलचस्प फायदे सरल इकाई परीक्षण की तुलना में:

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

क्या आप स्टेटमेंट में उद्देश्य से "यूनिट" से चूक गए हैं: "हालांकि आप परीक्षण का उपयोग किए बिना संचालित विकास का परीक्षण नहीं कर सकते।" ?

— रतोकोन

@ratkok: ऐसा कोई भी उद्देश्य नहीं था। मुझे वह ठीक करने दो।

मुझे यह परिभाषा सबसे अच्छी लगती है। यह अन्य उत्तरों की तुलना में शब्दों में एक साथ रखा गया है।

— टेक

2

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

— टोबे स्पाइट

13

टीडीडी और यूनिट परीक्षण दो बहुत ही विशिष्ट शब्द हैं जिनका अक्सर दुरुपयोग होता है।

टीडीडी एक परीक्षण लिख रहा है जो विफल हो जाएगा, फिर इसे चलाने के लिए आवश्यक न्यूनतम कोड लिखना, फिर कोड को साफ करने के लिए फिर से भरना। यह चक्र में किया जाता है, असफल -> पास -> रिफ्लेक्टर, कोड के लिए प्रत्येक ज्ञात आवश्यकता के लिए एक नया परीक्षण जोड़ना। हाल ही में, TDD उस चक्र में इकाई परीक्षणों को लिखने के बारे में और भी विशेष रूप से बन गया है, इसे ATDD (BDD का सबसेट) से अलग करने के लिए जो एक समान चक्र में स्वीकृति परीक्षण लिख रहा है।

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

— PDR
स्रोत

1

JUnit के लिए JUnit परीक्षण स्वयं एक अच्छा उदाहरण हैं: उन लोगों का एक महत्वपूर्ण भाग कार्यात्मक परीक्षण और स्वीकृति परीक्षण हैं, यूनिट परीक्षण नहीं, भले ही वे JUnit में लिखे गए हों। इसके अलावा, JUnit का निर्माता भी TDD का निर्माता होता है, और JUnit को TDD का उपयोग करके कार्यात्मक परीक्षणों और स्वीकृति परीक्षणों की एक महत्वपूर्ण मात्रा का उपयोग करके विकसित किया गया था। स्वीकृति परीक्षण टीडीडी का एक अभिन्न अंग है।

— जर्ग डब्ल्यू मित्तग

6

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

— M.Sameer
स्रोत

3

TDD कोड लिखने के लिए एक दार्शनिक दृष्टिकोण है: पहले परीक्षण लिखें। आपके द्वारा लिखे गए परीक्षण इकाई परीक्षण हैं।

— Tangurena
स्रोत

1

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

— ग्रांट पॉलिन
स्रोत

1

सभी उत्कृष्ट उत्तर। मैं केवल उस इकाई परीक्षण को 'इकाई' के एक छोटे घटक के रूप में मानता है, जबकि टीडीडी एकीकरण और स्वीकृति परीक्षणों को शामिल करता है।

(कुछ टीडीडी वेरिएंट 'यूनिट' को वांछित कार्यक्षमता की दिशा में सबसे छोटा वृद्धिशील कदम मानते हैं ...)

— स्टीवन ए लोव
स्रोत

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

— 19:11

1

@jwenting उन लोगों की कमियों के लिए कार्यप्रणाली को दोष नहीं देते जो इसे अभ्यास करने का दावा करते हैं। किसी भी उपकरण का दुरुपयोग किया जा सकता है

— स्टीवन ए। लोव

1

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

— 20'11

यह देखते हुए कि TDD डिजाइन के बारे में है - इसमें स्वीकृति परीक्षण क्यों शामिल होगा? यह डिजाइन को "कैसे" चलाएगा?

— विटाली इसेंको

@VitaliiIsaenko स्वीकृति परीक्षण डिजाइनों के लिए उच्चतम-स्तरीय स्कूपिंग प्रदान करता है

— स्टीवन ए। लोवे