bdd - क्या बीडीडी परीक्षण स्वीकृति परीक्षण हैं?




fitnesse acceptance-testing (5)

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

उस फ़ोकस के कारण, वार्तालाप BDD टूल की तुलना में बहुत अधिक महत्वपूर्ण हैं।

मैं फिर से कहने जा रहा हूं। बातचीत बीडीडी टूल की तुलना में बहुत अधिक महत्वपूर्ण हैं।

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

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

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

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

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

एक बार फिर। बातचीत बीडीडी टूल की तुलना में बहुत अधिक महत्वपूर्ण हैं।

कृपया, कृपया, टूल पर फिक्स न करें। उपकरण वार्तालापों को कैप्चर करने और कोड में खेलने के लिए सुनिश्चित करने के लिए सिर्फ एक तंत्र हैं। परिदृश्य बातचीत के लिए एक प्रतिस्थापन नहीं हैं, 3 x 5 इंडेक्स कार्ड से अधिक कोई भी आवश्यकताओं के लिए एक प्रतिस्थापन है।

कहा जा रहा है कि, यदि आपको एक उपकरण के साथ शुरू करना है, तो फिटनेस के पीछे स्लिम डाल दें ताकि यह फिट के तालिकाओं और जुड़नार के साथ गड़बड़ किए बिना सुंदर गिवेन / व्हेन / थेंस चला सके। GivWenZen स्लिम और उनमें से किसी भी चट्टान पर आधारित है। .NET स्पेस में आप के लिए FitSharp बराबर है। या बस ककड़ी, या SpecFlow का उपयोग करें, या थोड़ा कस्टम डीएसएल * खटखटाएं जो सालों तक काम ठीक करेगा।

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

भले ही - बातचीत पहले से ही है। यह सिर्फ लोग हैं। जाओ बात करो।

या, यदि आपके पास बीडीडी परीक्षण हैं, तो क्या आपको फिटनेस जैसी किसी चीज की आवश्यकता है?


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

यह कैसे काम करता है, इसका अंदाजा लगाने के लिए मैं JBehaves 2min ट्यूटोरियल का सुझाव देता हूं


जबकि BDD सिर्फ परीक्षणों के दायरे से बड़ा है, वास्तव में BDD परीक्षण हैं। ये परीक्षण यूनिट टेस्ट हैं जो बीडीडी भाषा का पालन करते हैं।

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

आपकी वरीयता की भाषा के आधार पर कुछ अच्छे BDD फ्रेमवर्क उपलब्ध हैं। .NET के लिए रूबी JBehave लिए जावा RSpec लिए NBehave


फ्लेक्स में BDD परीक्षण के लिए आप GivWenZen-flex की जांच कर सकते हैं, इसे http://bitbucket.org/loomis/givwenzen-flex

चीयर्स, क्रि


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

जब आप "बीडीडी फ्रेमवर्क" के बारे में सुनते हैं, तो स्पीकर का मतलब आमतौर पर आपके सभी प्रकार के परीक्षणों को लिखने के लिए एक फ्रेमवर्क होता है लेकिन एक बीडीडी ट्विस्ट के साथ। उदाहरण के लिए, RSpec में, आप अभी भी इकाई परीक्षण लिखते हैं; आप बस उन्हें बीडीडी स्वाद जोड़ें।