BDD का उपयोग करते समय इकाई परीक्षणों का उपयोग कैसे करें?


18

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

एक व्यावहारिक बिंदु है जो मुझे नहीं मिलता है, सोचा: एक .feature फ़ाइल है जिसमें बीए सभी अपेक्षित व्यवहार लिखेगा जिसमें सिस्टम होगा। एक बीए के रूप में, उसे पता नहीं है कि सिस्टम कैसे बनता है, इसलिए हम कुछ इस तरह लिखेंगे:

+ परिदृश्य 1: खाता क्रेडिट + में है

यह देखते हुए कि खाता क्रेडिट में है

और कार्ड मान्य है

और डिस्पेंसर में नकदी होती है

जब ग्राहक नकदी का अनुरोध करता है

फिर यह सुनिश्चित करें कि खाता डेबिट हो गया है और यह सुनिश्चित हो गया है कि नकदी समाप्त हो गई है

और सुनिश्चित करें कि कार्ड वापस कर दिया गया है

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

मैं यूनिट टेस्ट करवाना चाहूंगा। यदि डिस्पेंसर के पास पैसा है तो मैं उस कोड का परीक्षण कैसे करूं? या कि नकदी को छितरा दिया है? या आवश्यकता पड़ने पर खाता डेबिट किया जाता है? मैं "बीए निर्मित" परीक्षणों के साथ इकाई परीक्षण कैसे मिश्रण कर सकता हूं?


यह है कि मोज़ेक और स्टब्स के लिए हैं: परीक्षण के तहत भागों को अलग करना।
रॉबर्ट हार्वे

क्षमा करें, मुझे यह नहीं मिला। आपका मतलब है कि मुझे डिस्पेंसर का मजाक उड़ाना चाहिए? मैं इसका परीक्षण कैसे करूंगा?
JSBach

जब आप डिस्पेंसर का परीक्षण कर रहे होते हैं, तो आप खाते, कार्ड और ग्राहक का मजाक उड़ाते हैं।
रॉबर्ट हार्वे

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

@DocBrown: "स्वाभाविक रूप से उभर कर," मेरा मतलब है कि कुछ TDD'ers का मानना ​​है कि एक सॉफ्टवेयर डिज़ाइन स्वाभाविक रूप से यूनिट परीक्षणों से निकलेगा जैसा कि आप "रेड-ग्रीन-रिफ्लेक्टर।" इस प्रश्न के बारे में बातचीत की शुरुआत व्हाइटबोर्ड में हो रही है ।
रॉबर्ट हार्वे

जवाबों:


28

व्यवहार प्रेरित विकास और परीक्षण प्रेरित विकास प्रशंसात्मक हैं, लेकिन एक दूसरे के लिए प्रतिस्थापन नहीं।

अनुप्रयोग "व्यवहार करता है" को कैसे स्वीकार किया जाता है स्वीकार्यता टेस्ट में, जो बीडीडी के अनुसार ककड़ी में लिखी गई विशेषताएँ और परिदृश्य होंगे।

यूनिट टेस्ट में प्रत्येक छोटे घटक के काम करने के तरीके के बारे में विस्तृत जानकारी दी गई है। यूनिट टेस्ट के परिणाम आपको ककड़ी में लिखे परिदृश्यों का समर्थन करते हैं।

कार बनाने की प्रक्रिया की कल्पना करें।

सबसे पहले, उत्पाद टीम अपने विचारों के साथ आती है, और अंततः उन्हें उपयोग परिदृश्यों के लिए उबालती है:

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

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

ऊपर का परिदृश्य "बिग पिक्चर" टेस्ट है। वाहन के प्रत्येक घटक को "छोटे चित्र" परीक्षणों की आवश्यकता होती है ताकि यह सुनिश्चित हो सके कि वे पूरी तरह से ठीक से काम करते हैं।

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

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

एक बार यूनिट टेस्ट पास होने के बाद, ककड़ी परिदृश्यों को लागू करना शुरू करें। एक बार जब वे पास हो रहे हैं, तो आपने उत्पाद टीम से पूछा है कि क्या दिया है।


क्या उन "बिग पिक्चर" परीक्षणों को "स्मॉल पिक्चर" परीक्षणों से जोड़ने का एक तरीका है? मेरा मतलब है, जब सुविधाएँ आधिकारिक तौर पर बदलती हैं (एक बदलते ककड़ी परिदृश्य कहते हैं), तो क्या कम अंत परीक्षणों में परिवर्तन का नक्शा बनाने का एक तरीका है (जूनून परीक्षण जो उस विशेष ककड़ी परिदृश्य के लिए हैं)?
श्रीकांत

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

[...] जो BDD के अनुसार ककड़ी में लिखी गई विशेषताएँ और परिदृश्य होंगे। आप सिद्धांतों और टूलींग को भ्रमित कर रहे हैं।
जुब

ठीक है, ठीक है, शब्दांकन थोड़ा बंद है, लेकिन बिंदु एक आवेदन का व्यवहार है जो सुविधाओं और परिदृश्यों में कैद है।
ग्रेग बर्गार्ड्ट

9

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

असल में, नहीं, BDD है नहीं TDD से "अगले कदम"। यह है TDD। या अधिक सटीक रूप से, यह टीडीडी का एक रीफ़्रेशिंग है।

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

इसलिए, उन्होंने व्यवहार विनिर्देश के संदर्भ में टीडीडी को फिर से परिभाषित किया। "परीक्षण" और "परीक्षण के मामले" अब "उदाहरण" हैं, "इकाइयां" "व्यवहार" हैं, "दावे" "अपेक्षाएं" हैं, और इसी तरह।

हालांकि, कार्यप्रणाली अभी भी समान है। आप एक स्वीकृति परीक्षण (मेरा मतलब "सुविधा") से शुरू करते हैं, एक इकाई परीक्षण में ज़ूम करें (मेरा मतलब है "उदाहरण"), ज़ूम बैक आदि।

मैं यूनिट टेस्ट करवाना चाहूंगा। यदि डिस्पेंसर के पास पैसा है तो मैं उस कोड का परीक्षण कैसे करूं? या कि नकदी को छितरा दिया है? या आवश्यकता पड़ने पर खाता डेबिट किया जाता है? मैं "बीए निर्मित" परीक्षणों के साथ इकाई परीक्षण कैसे मिश्रण कर सकता हूं?

उसी तरह से आप टीडीडी में करते हैं। आप अपनी सुविधाओं और अपने उदाहरणों को विभिन्न चौखटों (जैसे ककड़ी और आरएसपीईसी) या यहां तक ​​कि अलग-अलग भाषाओं में लिख सकते हैं (जैसे कि सी में सी परियोजना के लिए उदाहरण लिखना और एफआईटी / फिटनेस में विशेषताएं), आप दोनों के लिए एक एकल फीचर ढांचे का उपयोग कर सकते हैं () उदाहरण के लिए ककड़ी में उदाहरण और सुविधाएँ लिखना) या आप दोनों के लिए एकल उदाहरण रूपरेखा का उपयोग कर सकते हैं (जैसे RSpec में दोनों लिखना)। तुम भी एक रूपरेखा का उपयोग करने की जरूरत नहीं है।

TDD- किया-दाएं (जो BDD के समान है) का एक उदाहरण सिर्फ एक ही फ्रेमवर्क का उपयोग करना है, जो स्वयं JUnit है, जिसमें इकाई परीक्षण (उदाहरण) और कार्यात्मक / एकीकरण परीक्षण (सुविधाएँ) का मिश्रण है, जो JUnit में ही लिखे गए हैं।

मेरा मानना ​​है कि केंट बेक इसे "जूमिंग" कहता है। उच्च-स्तरीय प्रारंभ करें, फिर विवरणों में "ज़ूम इन" करें, फिर से वापस जाएं।


1

डिस्क्लेमर: मैं बीडीडी का विशेषज्ञ नहीं हूं, लेकिन मैं आपको जिस आर्टिकल से जुड़ा हुआ हूं, उस पर अपनी बात रखने की कोशिश करता हूं।

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

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

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

इसके अलावा, BDD परिदृश्यों भी एकीकरण परीक्षणों के लिए एक खाका होगा - जो आप आमतौर पर जोड़ देगा के बाद आप TDD द्वारा विधि के नाम बाहर fleshed है और तुम्हारे जाने के बाद इकाई परीक्षण के लिए उचित समय जोड़ा।

इसलिए, मेरी समझ में, TDD एक ऐसा साधन है जिसे आप BDD के भाग के रूप में उपयोग कर सकते हैं, और BDD आपको सही परीक्षण लिखने और उन्हें बेहतर नाम देने में मदद करता है।


एक त्वरित बिंदु के रूप में, जूनित आपके परीक्षणों के नामकरण का समर्थन करता है; आपको बस एक @ टिप्पणी एनोटेशन का उपयोग करना होगा। यह 2003 में वापस नहीं किया है, हालांकि हो सकता है।
सोरू

2003 में @soru बैक ने वास्तव में "टेस्ट" शब्द को लागू किया।
लुनिवर

लेख के लेखक डैन नॉर्थ हैं, जो पहली बार अवधारणा के साथ आए थे। जिन चीजों पर उन्होंने ध्यान दिया उनमें से एक यह है कि "परीक्षण" शब्द हमें हमारे कार्यान्वयन (समाधान डोमेन) के परीक्षण के लिए स्थानांतरित करने का कारण बनता है जबकि वास्तव में, परीक्षण और खोज को परिभाषित करना वास्तव में हमें समस्या डोमेन में रखना चाहिए। डैन ने BDD को "क्या TDD होने का मतलब था" बताया है। अधिक जानकारी के लिए इसे पढ़ें: dannorth.net/2012/05/31/bdd-is-like-tdd-if
Lunivore
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.