क्या बीडीडी मध्यम से बड़ी परियोजनाओं के लिए स्केलेबल है?

Question

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

तो मैं सोच रहा था, क्या बीडीडी वास्तव में इसके लायक है? क्या यह एक ऐसी समस्या को हल करता है जो अन्य तकनीकों में नहीं है!

Comments

बहुत बुरा, मुझे लगता है कि यह मुद्दा काफी रचनात्मक है कि बीडीडी अधिक लोकप्रिय हो रहा है।

— डीडी

यदि पर्याप्त प्रतिनिधि वाला कोई व्यक्ति फिर से खोलने का सुझाव दे सकता है तो यह बहुत अच्छा होगा।

— डीडी

मैं फिर से खोलूंगा, लेकिन आपने पहले ही जवाब स्वीकार कर लिया ...

— MattDavey

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

— डीडी

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

— मैटवेवी

Answer 1

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

यदि आपके परीक्षणों में चीजें जटिल या अतिरंजित हो जाती हैं तो शायद आप कुछ गलत कर रहे हैं। यह BDD और TDD के साथ समान है। अच्छे परीक्षण लिखना कठिन है और इसे सीखने में महीनों लगते हैं।

Comments

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

— डीडी

आप कुछ जटिल बीडीडी परीक्षण संलग्न कर सकते हैं और मैं देख सकता हूं कि उन्हें सरल बनाने के लिए क्या किया जा सकता है।

— पायोत्र पेरक

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

— डीडी

इसे क्यों ठुकरा दिया गया? मैंने महान संसाधन दिए जो ओपी को उसकी समस्याओं को हल करने में मदद करेगा।

— पायोत्र पेरक

वह मुझे नहीं था, मैं क्षतिपूर्ति करने के लिए +1 दूंगा लेकिन मैं यह केवल 14 घंटों में कर सकता हूं क्योंकि मैंने आज के लिए अपने सभी 30 वोटों का उपयोग किया था।

— डीडी

Answer 2

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

मैंने बातचीत में सभी प्रकार के स्तरों पर परिदृश्यों का उपयोग किया है; विभिन्न हितधारकों की पहचान करने से लेकर यह देखने के लिए कि क्या रिलीज को अच्छी तरह से प्राप्त करने की संभावना है, यह पता लगाने के लिए कि मॉड्यूल या वर्ग को कैसे व्यवहार करना चाहिए ।

संकेत और युक्तियां हैं जो मैं इसे आसान बनाने के लिए सुझाव दे सकता हूं।

यदि आपने इसे पहले कभी नहीं किया है, तो यह बदलने जा रहा है।

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

सभी परियोजनाओं में कुछ पहलू हैं जो नए हैं, या आप उन्हें नहीं करेंगे।

यदि आपने इसे पहले किया है, तो यह उबाऊ है।

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

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

यदि किसी ने पहले किया है, तो परिदृश्यों के माध्यम से बात करने से मदद मिल सकती है।

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

परिदृश्यों के माध्यम से बात करने से देव टीम को व्यवहार की खोज करने में मदद मिल सकती है, एक विशेषज्ञ के ज्ञान को आकर्षित करने के लिए, और यह सुनिश्चित करने के लिए कि ज्ञात, मूल्यवान व्यवहार पर कब्जा कर लिया गया है।

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

जहाँ भी संभव हो, परिदृश्यों का उपयोग उदाहरण के रूप में करें कि आवेदन कैसे काम करता है । उदाहरण के लिए, यदि आप यह दिखाना चाहते हैं कि सत्यापन कैसे काम करता है, तो कुछ उदाहरणों के बारे में बताएं कि कैसे एप्लिकेशन उपयोगकर्ता को फ़ॉर्म भरने में मदद करता है। जाँच लें कि इकाई परीक्षण का उपयोग करके सत्यापन कठोर है, जिसे बनाए रखना और चलाना बहुत आसान है।

आगे की पढाई

यदि आप इसमें रुचि रखते हैं, तो यहां कुछ चीजें मैंने लिखी हैं जो मदद कर सकती हैं।

बड़े में बी.डी.डी.

देवों के लिए Cynefin , जो अधिक विस्तार से इन तीन क्षेत्रों में जाता है

मेरे ट्यूटोरियल स्लाइड , जो आपके लिए सभी अच्छे और एनोटेट हैं, और पूरे स्टैक को भी कवर करते हैं।

Comments

इस जानकारीपूर्ण उत्तर के लिए धन्यवाद, आपके द्वारा संलग्न लिंक को पढ़ें

— DD

Answer 3

हमने एक काफी जटिल ( डोमेन जटिलता ) परियोजना का निर्माण किया है और मैं ईमानदारी से कह सकता हूं कि बीडीडी में काम करने से परियोजना को बचाया जा सकता है। मैंने डोमेन जटिलता और BDD के लाभों के बीच एक मजबूत संबंध देखा है।

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

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

Answer 4

BDD एक विकास प्रक्रिया है जो TDD (टेस्ट ड्रिवेन डेवलपमेंट) पर आधारित है। यहाँ कुछ व्यक्तिगत अनुभव से तैयार किए गए TDD के कुछ पक्ष और विपक्ष हैं:

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

विपक्ष:

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

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

Comments

आपको BDD और TDD और जहाँ DDD भाग में आता है, के बीच के अंतरों के बारे में विस्तार से बताना चाहिए।

— बेंजामिन ग्रुएनबाउम

@BenjaminGruenbaum आदर्श रूप से, BDD और TDD में कोई अंतर नहीं है। BDD जब ठीक से पालन किया जाता है तो TDD के समान होता है! इसलिए मैंने जवाब के एक हिस्से के रूप में अंतर लाने के लिए कोई कारण नहीं देखा। फिर भी सुझाव के लिए धन्यवाद!

— विकेटकीपिंग

"TDD एक तेज़ सॉफ़्टवेयर विकास की अनुमति देता है।" क्या इसकी पुष्टि करने वाले कोई अध्ययन थे? बस उत्सुक। मैं यह भी उल्लेख करूंगा कि स्पीड-अप रैखिक नहीं है।

— डेन

@AlexandreMartins Hah, बिल्कुल! यह पहचानने के लिए बहुत अधिक महत्वपूर्ण है कि आपके पास खराब गुणवत्ता परीक्षण और परिदृश्य हो सकते हैं, यह दिखावा करने के लिए कि वे सभी अच्छे IMO हैं।

— लूनीवर

@Lunivore हां, जो मुझे BDD / TDD के मामले में परेशान करता है। परीक्षण के मामलों को मजबूत करने की आवश्यकता है। दुर्भाग्य से विकास समुदाय में यह दृष्टिकोण है कि जब तक परीक्षण के मामले हैं, यह ठीक है! मैंने एक बार एक परीक्षण मामले को देखा जहां एक sql स्टेटमेंट का उपयोग करके एक तालिका में एक पंक्ति डाली जा रही थी और उसी को अगले चरण पर मुखर किया जा रहा था! क्या डेवलपर oracle कार्यक्षमता का परीक्षण करने की कोशिश कर रहा था?!

— Ricketyship