बीडीडी और टीडीडी के बीच संबंध

बीडीडी और टीडीडी का क्या संबंध है?

जो मैंने समझा था कि BDD TDD के ऊपर दो मुख्य बातें जोड़ता है: परीक्षण नामकरण (सुनिश्चित / करना) और स्वीकृति परीक्षण। क्या मुझे BDD द्वारा विकास के दौरान TDD का पालन करना चाहिए? यदि हाँ, तो क्या मुझे सुनिश्चित करना चाहिए कि क्या मेरे TDD इकाई परीक्षणों का नाम एक ही है?

tdd bdd

— SiberianGuy
स्रोत

BDD अच्छी तरह से प्रलेखित TDDs (यूनिट्स) का एक सेट है

— DD

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

— पॉल हिक्स

BDD और TDD के बीच का अंतर माइक्रोइकॉनॉमिक्स के साथ मैक्रोइकॉनॉमिक्स के बीच अंतर की तरह है। BDD = उदाहरणों का उपयोग करके आवश्यकताओं की समझ का निर्माण करना और स्वचालित मैक्रो परीक्षणों को चलाने के लिए वैकल्पिक रूप से उपयोग किया जा सकता है। (agilenoir.biz/en/am-i-behavioral-or-not), TDD = लेखन कोडिंग को चलाने के लिए सूक्ष्म परीक्षण लिखना। फुर्तीली विचार पॉडकास्ट इन अंतरों को भी कवर करता है: agilenoir.biz/en/agilethoughts/test-automation-pyramid-series

— लांस

जवाबों:

BDD, TDD चक्र के चारों ओर एक चक्र जोड़ता है।

तो आप एक व्यवहार के साथ शुरू करते हैं और उस परीक्षण को चलाने देते हैं, फिर परीक्षणों को चलाने दें। आदर्श रूप से, BDD किसी प्रकार के स्वीकृति परीक्षण से प्रेरित है, लेकिन यह 100% आवश्यक नहीं है। जब तक आपके पास अपेक्षित व्यवहार परिभाषित है, तब तक आप ठीक हैं।

तो, मान लीजिए कि आप एक लॉगिन पृष्ठ लिख रहे हैं।

खुश पथ से शुरू करें:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

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

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

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

तो अब उस कार्यक्षमता को प्रदान करने के लिए टीडीडी चक्र पर जाने का समय आ गया है।

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

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

और फिर हम अगले व्यवहार के लिए आगे बढ़ते हैं।

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

अब आपको अपने पहले के व्यवहार को पारित करने के लिए इसे पूर्व निर्धारित नहीं करना चाहिए था। आपको इस बिंदु पर इस परीक्षण को विफल करना चाहिए। इसलिए वापस अपने टीडीडी चक्र पर जाएं।

और इसी तरह जब तक आपके पास अपना पेज न हो।

BDD और TDD के बारे में अधिक जानने के लिए Rspec बुक की अत्यधिक अनुशंसा करें , भले ही आप रूबी डेवलपर न हों।

— PDR
स्रोत

क्या आप सिर्फ टिप्पणियां डाल सकते हैं? मैं अभी भी नहीं मिला ...

— हनी

इसकी मेरी समझ:

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

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

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

से http://www.metesreau.com/ncraft-workshop/

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

में कार्रवाई में BDD जॉन फर्ग्यूसन स्मार्ट (अत्यधिक की सिफारिश की) द्वारा, वह एक डबल पाश दृष्टिकोण की वकालत, बाहरी स्तर निष्पादन विनिर्देशों पर jBehave की तरह कुछ के साथ शुरू है, तो निम्न स्तर के विनिर्देशों के लिए स्पॉक की तरह एक उपकरण में छोड़ने।

BDD व्यवसाय-हितधारकों के करीब परीक्षण-संचालित की अवधारणा लाता है। घेरकिन को व्यापार पठनीय बनाया गया है, और 'जीवित प्रलेखन' का विचार, यानी अपने निष्पादन योग्य विनिर्देशों से स्वचालित रूप से प्रगति रिपोर्ट तैयार करना हितधारकों को प्रतिक्रिया देना है।

BDD का एक और हिस्सा, जो कि जहां यह वास्तव में एक ऐसी चीज बन जाता है, जो TDD को एक बड़ी प्रक्रिया के हिस्से के रूप में शामिल करता है, वे हैं आवश्यकताएं इलीटेशन बिट्स और टुकड़े। फ़ीचर इंजेक्शन, इम्पैक्ट मैपिंग और रियल ऑप्शन जैसे विचार इस पक्ष का हिस्सा हैं।

इस पर विहित उत्तर के लिए, फिर से दान उत्तर में जाना सबसे अच्छा हो सकता है । यदि आपकी टीम सभी डेवलपर्स है, तो BDD = TDD। यदि आपकी टीम में हितधारकों की एक पूरी श्रृंखला शामिल है, BDD XP के करीब है, जिसमें TDD इसका एक हिस्सा है।

— एन जी एम
स्रोत

बीडीडी और टीडीडी का क्या संबंध है?

वे एक जैसी ही चीज हैं।

बीडीडी ने मुझे समझा कि टीडीडी पर दो मुख्य बातें हैं: नामकरण परीक्षण (सुनिश्चित / होना चाहिए)

यह वास्तव में कुछ नहीं है BDD "कहते हैं"। यह सिर्फ एक अलग सम्मेलन है जो टीडीडी को सिखाने और समझने में आसान बनाने के लिए है।

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

लेकिन यह केवल शब्द है! नहीं है कोई TDD और BDD के बीच वास्तविक अंतर।

और स्वीकृति परीक्षण।

स्वीकृति परीक्षण केवल टीडीडी का एक महत्वपूर्ण हिस्सा हैं क्योंकि वे बीडीडी के हैं। फिर: TDD सही किया: वहाँ TDD और BDD बीच कोई अंतर नहीं है BDD BDD, है TDD किया सही।

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

किस तरह से स्वीकृति परीक्षण TDD का एक महत्वपूर्ण हिस्सा हैं?

— साइबेरियनग्यू

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

— gbjbaanb

@ भारत: जिस तरह से वे बीडीडी के लिए महत्वपूर्ण हैं, उसी तरह, चूंकि दोनों एक ही चीज हैं ! स्वीकृति परीक्षण, TDD के बाहरी चक्र को ड्राइव करता है, जो सुविधाओं और उपयोगकर्ताओं के साथ व्यवहार करता है, जैसा कि अधिक विस्तृत आंतरिक चक्र के विपरीत होता है जो एपीआई और प्रोटोकॉल और इस तरह से व्यवहार करता है। मुझे लगता है कि केंट बेक इसे "ज़ूम इन / ज़ूम आउट" कहता है। उदाहरण के लिए, आप इसे आसानी से JUnit परीक्षण सूट में देख सकते हैं, जिसमें संभवतः कम से कम कई स्वीकृति परीक्षण शामिल हैं क्योंकि इसमें इकाई परीक्षण शामिल हैं।

— डब्ल्यू

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

— पीडीआर

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

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