टीडीडी और बीडीडी के बीच प्राथमिक मतभेद क्या हैं?

व्यवहार संचालित विकास डेवलपर्स और डेवलपर्स और परीक्षकों के बीच बातचीत और संचार पर अधिक ध्यान केंद्रित करने लगता है।

विकिपीडिया लेख में एक स्पष्टीकरण है:

व्यवहार-संचालित विकास

हालांकि बीडीडी का अभ्यास नहीं कर रहा हूं।

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

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

बीडीडी का प्रयोग संचार उपकरण के रूप में भी किया जाता है। लक्ष्य निष्पादन योग्य विनिर्देशों को लिखना है जिन्हें डोमेन विशेषज्ञों द्वारा समझा जा सकता है।

मैं परीक्षण की तुलना में विनिर्देश के बारे में अधिक होने के लिए बीडीडी को समझता हूं। यह डोमेन संचालित डिजाइन से जुड़ा हुआ है (क्या आप इन * डीडी शब्दकोषों से प्यार नहीं करते हैं?)।

यह उच्च स्तरीय परीक्षणों सहित उपयोगकर्ता कहानियों को लिखने के एक निश्चित तरीके से जुड़ा हुआ है। टॉम दस द्वारा एक उदाहरण Thij :

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

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

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

You will find a comparison of BDD and TDD in this video. Also an opinion about BDD as "TDD done right" by Jeremy D. Miller

25 मार्च, 2013 अपडेट

उपरोक्त वीडियो थोड़ी देर के लिए गायब हो गया है। यहां हाल ही में लेवेलिन फाल्को, बीडीडी बनाम टीडीडी (समझाया गया) है। मुझे उनकी व्याख्या स्पष्ट और बिंदु पर मिलती है।

Difference between test-driven development (TDD) and behavior-driven development (BDD)

• बीडीडी
  के बजाए सिस्टम के व्यवहार पहलू पर केंद्रित है सिस्टम के कार्यान्वयन पहलू जिस पर टीडीडी केंद्रित है।

• बीडीडी एक स्पष्ट समझ देता है कि सिस्टम को क्या करना चाहिए
  डेवलपर और ग्राहक के परिप्रेक्ष्य से। केवल टीडीडी
  डेवलपर को सिस्टम को क्या करना चाहिए इसकी समझ देता है।

• बीडीडी डेवलपर और ग्राहक दोनों को मिलकर काम करने की अनुमति देता है आवश्यकता विश्लेषण जो स्रोत कोड के भीतर निहित है प्रणाली।

त्वरित स्नैपशॉट यहां दिया गया है:

• TDD is just the process of testing code before writing it!

• DDD is the process of being informed about the Domain before each cycle of touching code!

• BDD is an implementation of TDD which brings in some aspects of DDD!

उम्मीद है की वो मदद करदे!

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

टीडीडी परीक्षण पर ध्यान केंद्रित करता है। और चूंकि "पुरानी झरना दुनिया" परीक्षण कार्यान्वयन के बाद आते हैं, तो यह मानसिकता गलत समझ और व्यवहार की ओर ले जाती है।

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

बीडीडी काफी हद तक टीडीडी सही है। हालांकि, अतिरिक्त मूल्य है कि बीडीडी ऑफर करता है। यहां एक लिंक दिया गया है:

बीडीडी से अधिक है? टीडीडी सही है ?

This blog provides an interesting viewpoint on the differences between TDD, BDD, and ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/

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

डिजाइन करने के लिए टीडीडी के प्राथमिक लाभ पर विचार करें। इसे टेस्ट ड्राइव डिजाइन कहा जाना चाहिए। बीडीडी टीडीडी का सबसेट है, इसे व्यवहार संचालित डिजाइन कहते हैं।

अब टीडीडी - यूनिट परीक्षण के लोकप्रिय कार्यान्वयन पर विचार करें। यूनिट परीक्षण में इकाइयां आमतौर पर तर्क का एक बिट होता है जो आपके द्वारा किए जा सकने वाले काम की सबसे छोटी इकाई है।

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

मैं जोड़ूंगा कि बीडीडी परीक्षण जीवित आवश्यकताओं के रूप में कार्य करते हैं।

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

कुछ लोग तर्क देते हैं कि बीडीडी हमेशा टीडीडी से बेहतर है क्योंकि टीडीडी का उपयोग करते समय उत्पन्न होने वाले मुद्दों को खत्म करने की संभावना है।

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

Test-Driven Development is a test-first software development methodology, which means that it requires writing test code before writing the actual code that will be tested. In Kent Beck?s words:

यहां शैली कोड की कुछ पंक्तियां लिखना है, फिर एक परीक्षण है   एक परीक्षण लिखने के लिए दौड़ना चाहिए, या इससे भी बेहतर, दौड़ना नहीं होगा, फिर लिखें   वह कोड जो इसे चलाएगा।

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

तो टीडीडी एक निम्न-स्तर, तकनीकी पद्धति है जो प्रोग्रामर स्वच्छ कोड तैयार करने के लिए उपयोग करते हैं जो काम करता है।

Behavior-Driven Development is a methodology that was created based on TDD, but evolved into a process that doesn?t concern only programmers and testers, but instead deals with the entire team and all important stakeholders, technical and non-technical. BDD started out of a few simple questions that TDD doesn?t answer well: how much tests should I write? What should I actually test?and what shouldn?t I? Which of the tests I write will be in fact important to the business or to the overall quality of the product, and which are just my over-engineering?

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

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

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

और जानें

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

यदि आप खरीदने में रुचि रखते हैं? महान विनिर्देशों को लिखना ,? प्रोमो कोड 39nicieja2 के साथ आप 39% को सहेज सकते हैं :)