व्यवहार प्रोग्रामिंग का परिचय (BDD)

इतिहास: यह लेख पहली बार मार्च 2006 में बेटर सॉफ्टवेयर पत्रिका में प्रकाशित हुआ। इसका कई भाषाओं में अनुवाद किया गया है।

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

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

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

वाक्यों के साथ परीक्षणों (विधियों) के नामों को व्यक्त करें

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

public class CustomerLookupTest extends TestCase { testFindsCustomerById() { ... } testFailsForDuplicateCustomers() { ... } ... } 

यह कुछ इस तरह से प्रिंट करता है:

CustomerLookup

• आईडी द्वारा ग्राहक पाता है
• नकली ग्राहकों के लिए विफल रहता है
• ...

(नोट "CustomerLookup [ग्राहक खोज]: आईडी द्वारा ग्राहक को ढूंढता है; यदि ग्राहक दोहराता है तो ड्रॉप करता है")

शब्द "परीक्षण" को वर्ग नाम और विधियों से हटा दिया जाता है, और ऊंट का नाम रिकॉर्ड सादे पाठ में बदल जाता है। वह सब करती है, लेकिन प्रभाव अद्भुत है।

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

कोई गलती न करें, इस सरल परीक्षण प्रस्ताव टेम्पलेट का उपयोग करें।

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

उदाहरण के लिए, एक बार, मैं एक वर्ग लिखता हूं जो स्क्रीन से इनपुट की जांच करता है। अधिकांश फ़ील्ड साधारण ग्राहक विवरण हैं: पहला नाम, अंतिम नाम, और बहुत कुछ; लेकिन फिर जन्म की तारीख के लिए एक क्षेत्र था और उम्र के लिए दूसरा। मैंने 'TestShouldFailForMissingSurname' जैसे तरीकों से 'ClientDetailsValidatorTest` (क्लाइंट विवरणों का नोट नोट करने वाला ) लिखना शुरू कर दिया ( ध्यान दें कि यदि कोई अंतिम नाम नहीं है तो परीक्षा विफल हो जाएगी) और `testShouldFailForMissingTitle` ( नोट का कोई शीर्षक नहीं होने पर परीक्षण विफल हो जाएगा)।

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

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

 public class ClientDetailsValidator { private final AgeCalculator ageCalc; public ClientDetailsValidator(AgeCalculator ageCalc) { this.ageCalc = ageCalc; } } 

एक साथ वस्तुओं को बनाने की यह शैली, जिसे निर्भरता इंजेक्शन के रूप में जाना जाता है, विशेष रूप से नकली वस्तुओं के साथ उपयोगी है।

परीक्षणों को स्पष्ट रूप से नाम दें: जब वे गिरते हैं तो मदद करें

कुछ समय बाद, मैंने पाया कि कोड को संशोधित करके और परीक्षणों को तोड़कर, मैं उनके नामों से कोड के अपेक्षित व्यवहार को स्पष्ट रूप से समझ सकता था। आमतौर पर, तीन चीजों में से एक:

• मैंने गलत कोड लिखा था। मुझे बुरा। समाधान: कोड को ठीक करें।
• व्यवहार महत्वपूर्ण था, लेकिन इसे कहीं स्थानांतरित कर दिया गया था। समाधान: परीक्षण को स्थानांतरित करें और संभवतः इसे बदलें।
• व्यवहार सत्य होना बंद हो गया है: सिस्टम के कार्य बदल गए हैं। समाधान: इस परीक्षण को हटा दें ।

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

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

"परीक्षण" के बजाय "व्यवहार" शब्द का उपयोग करें

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

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

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

मैंने पाया कि परीक्षण के बजाय व्यवहार के साथ सोच इतनी फायदेमंद थी कि मैंने व्यवहार या BDD के माध्यम से TDD परीक्षण को कॉल करना शुरू किया।

जेहेव व्यवहार पर केंद्रित है, परीक्षण का नहीं

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

काल्पनिक `CustomerLookup` ( लगभग ग्राहक खोज) वर्ग के लिए व्यवहार को परिभाषित करने के लिए, मैं नामक व्यवहार के लिए एक वर्ग लिखूंगा, उदाहरण के लिए,` CustomerLookupBehavior` ( लगभग ग्राहक खोज व्यवहार)। इसमें "इच्छा" ( नोट होना चाहिए) शब्द के साथ शुरू होने वाले तरीके शामिल होंगे। एक प्रोग्राम जो एक व्यवहार जांच ( लगभग व्यवहार धावक) शुरू करता है, फिर इस व्यवहार वर्ग का निर्माण करेगा और प्रत्येक तरीके को कॉल करेगा जो व्यवहार का वर्णन करता है, ठीक उसी तरह जैसे कि JUnit परीक्षणों के लिए करता है। फिर उसे निष्पादन के दौरान प्रगति पर रिपोर्ट करना होगा और अंत में एक परिणाम देना होगा।

मेरा पहला लक्ष्य था जेबीहेव का स्वयं परीक्षण करना। मैंने ऐसा व्यवहार जोड़ा जिसने इस कार्यक्रम को स्वयं चलाने की अनुमति दी। मैं JUeve व्यवहार के लिए सभी JUnit परीक्षणों को स्थानांतरित करने और JUnit के साथ एक ही प्रतिक्रिया प्राप्त करने में कामयाब रहा।

निम्नलिखित सबसे महत्वपूर्ण व्यवहार की पहचान करें

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

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

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

 public void shouldDoX() { // ... } 

अब मेरे पास टीडीडी के बारे में उस प्रश्न का उत्तर है, अर्थात्, कहाँ से शुरू करें।

आवश्यकताएँ व्यवहार भी हैं

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

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

BDD विश्लेषण के लिए "सभी भाषा के लिए खुला" प्रदान करता है

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

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

[X] के रूप में
मुझे [Y] चाहिए
ताकि [Z]

( लगभग। एक्स होने के नाते, मैं वाई चाहता हूं, इसलिए जेड क्या होता है)

जहां Y कुछ विशेषता है, Z इस सुविधा का लाभ या मूल्य है, और X व्यक्ति (या भूमिका) है। इस प्रस्ताव का लाभ यह है कि यह आपको इसकी पहली परिभाषा के दौरान विकसित होने वाली कहानी के महत्व को निर्धारित करने के लिए मजबूर करता है। आखिरकार, ऐसा होता है कि जब इतिहास का कोई वास्तविक व्यावसायिक महत्व नहीं होता है, तो कुछ इस तरह से गिरावट होती है: "... मुझे [कुछ सुविधा चाहिए], और इसीलिए [मैं इसे करता हूं, और यह ठीक है?] " हमारी विधि हमें सत्यापन के दायरे से परे इन बल्कि गूढ़ आवश्यकताओं को लेने की अनुमति देती है।

और इस शुरुआत से, मैट और मैं यह जानने की राह पर थे कि हर फुर्तीला परीक्षक पहले से ही जानता है: उपयोगकर्ता के इतिहास में व्यवहार सिर्फ एक स्वीकृति मानदंड है, अर्थात्, यदि सिस्टम सभी स्वीकृति मानदंडों को पूरा करता है, तो उसका व्यवहार सही है; यदि नहीं, तो नहीं। इसलिए, हमने उपयोगकर्ता कहानी के मूल्यांकन के लिए एक मानदंड रिकॉर्ड करने के लिए एक प्रस्ताव टेम्पलेट बनाया।

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

कुछ सन्दर्भ,
जब ( लगभग ) एक घटना होती है,
तब ( लगभग। तब) परिणाम की जाँच करें।

इसे प्रदर्शित करने के लिए, आइए एक क्लासिक एटीएम उदाहरण का उपयोग करें। एक कहानी कार्ड इस तरह दिख सकता है:

+ नाम: ग्राहक नकद वापस लेता है +
ग्राहक के रूप में
मैं एटीएम से पैसे निकालना चाहता हूं ,
इसलिए मुझे बैंक में लाइन में इंतजार नहीं करना पड़ेगा।

खैर, हम कैसे समझते हैं कि कहानी खत्म हो गई है? हमारे पास कई परिदृश्य हैं: खाते में पैसा है; खाते में कोई पैसा नहीं है, लेकिन ओवरड्राफ्ट के भीतर वापस लिया जा सकता है; ओवरड्राफ्ट से अधिक स्कोर। बेशक, अन्य परिदृश्य होंगे: खाता इस निकासी के साथ ओवरड्राफ्ट में होगा, या एटीएम में पैसा नहीं है।

जब-तब-तब पैटर्न का उपयोग करते हुए, पहले दो परिदृश्य इस तरह दिख सकते हैं:

दृश्य 1: खाते में धन है +
पैसे वाला खाता
और एक वैध कार्ड
और नकदी के साथ एक एटीएम
जब कोई ग्राहक नकद का अनुरोध करता है
फिर सुनिश्चित करें कि खाता डेबिट हो गया था
और सुनिश्चित करें कि नकदी जारी की गई है
और सुनिश्चित करें कि कार्ड वापस कर दिया गया है

ध्यान दें कि संघ का उपयोग करना और कई प्रारंभिक स्थितियों ( लगभग दिए गए) और परिणामों ( लगभग। फिर) को समझने की सुविधा को संयोजित करना।

+ परिदृश्य 2: निकासी ओवरड्राफ्ट + से अधिक है
सीमा से अधिक होने के साथ खाता होना
और एक वैध कार्ड
जब कोई ग्राहक नकद का अनुरोध करता है
फिर सुनिश्चित करें कि विफलता संदेश दिखाया गया है
और सुनिश्चित करें कि नकदी जारी नहीं की गई है
और सुनिश्चित करें कि कार्ड वापस कर दिया गया है

दोनों परिदृश्य एक ही घटना पर आधारित हैं और यहां तक ​​कि कई सामान्य आधारभूत स्थितियां और परिणाम भी हैं। हम आधारभूत स्थितियों, घटनाओं और परिणामों का फिर से उपयोग करके इससे लाभ उठा सकते हैं।

स्वीकृति मानदंड निष्पादित करें

इस परिदृश्य के टुकड़े - आधारभूत, घटना और परिणाम - क्रमादेशित होने के लिए काफी छोटे हैं। JBehave में एक ऑब्जेक्ट मॉडल है जो आपको जावा कक्षाओं के साथ स्क्रिप्ट के टुकड़ों को स्पष्ट रूप से सहसंबंधित करने की अनुमति देता है।

आप इस तरह से प्रत्येक प्रारंभिक स्थिति ( लगभग ) को दर्शाते हुए एक वर्ग लिखते हैं:

 public class AccountIsInCredit implements Given { public void setup(World world) { ... } } public class CardIsValid implements Given { public void setup(World world) { ... } } 

और उस घटना के लिए एक इस तरह है:

 public class CustomerRequestsCash implements Event { public void occurIn(World world) { ... } } 

और इसलिए स्क्रिप्ट के परिणामों के लिए। JBehave तब इसे एक साथ रखता है और प्रदर्शन करता है। यह एक "दुनिया" बनाता है जो कहीं न कहीं आपकी वस्तुओं को संग्रहीत करने के लिए मौजूद है, फिर जेबहेव इसे प्रत्येक प्रारंभिक स्थिति ( लगभग दिए गए) को पास करता है ताकि वे दुनिया को कुछ ज्ञात स्थिति के साथ आरंभ कर सकें। JBehave, तब इस दुनिया में एक "होने वाली" घटना के लिए पूछता है जो किसी विशेष परिदृश्य के घोषित व्यवहार को करता है। और अंत में, जेबेव किसी भी परिणाम पर नियंत्रण स्थानांतरित करता है जिसे हम किसी विशेष कहानी में परिभाषित करते हैं।

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

बीडीडी का वर्तमान और भविष्य

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

डेव एस्टल हाल ही में सक्रिय रूप से बीडीडी को बढ़ावा दे रहे हैं। उनके ब्लॉग और विभिन्न प्रकाशित लेखों ने गतिविधि की सुगबुगाहट को उकसाया। रूबी में BDD फ्रेमवर्क बनाने के लिए सबसे उल्लेखनीय rspec परियोजना है। मैंने रेबेवे पर काम शुरू किया, जो रूबी में जेबेव का कार्यान्वयन होगा।

मेरे सहयोगियों ने विभिन्न वास्तविक जीवन की परियोजनाओं में बीडीडी तकनीकों का उपयोग करने के बाद बताया कि यह विधि एक बड़ी सफलता है। JBehave उप-कहानी चलाने के लिए - स्वीकृति मानदंड की जाँच करने वाला हिस्सा सक्रिय रूप से विकसित किया जा रहा है।

भविष्य में, हम चाहते हैं कि एक पूर्ण सर्कल संपादक हो जो व्यापार विश्लेषकों और परीक्षकों को एक नियमित पाठ संपादक में कहानियां लिखने की अनुमति देगा, जो व्यवसाय मॉडल की भाषा में व्यवहार कक्षाओं के लिए स्टब ऑब्जेक्ट बनाएंगे। BDD कई लोगों की मदद से विकसित हुआ है और मैं उनके प्रति अपनी गहरी कृतज्ञता व्यक्त करता हूं।

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