BDD इसके विपरीत

मैंने बीडीडी के बारे में पढ़ा, और मुझे एक बात का एहसास हुआ कि बीडीडी ब्लाब ब्लाब ब्लाब है। उसकी सामान्य परिभाषा नहीं है। यहाँ, उदाहरण के लिए, लिखा है:

BDD सॉफ्टवेयर विकास के दौरान एक सामान्य सहभागिता प्रक्रिया के साथ प्रोग्रामर, परीक्षक, विश्लेषकों और प्रबंधकों को प्रदान करने के लिए बुनियादी तकनीकों और प्रथाओं TDD और DDD के विचारों को जोड़ती है।

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

कई बग के साथ जीरा इश्यू दिया
जब कि सभी कीड़े तय हो गए हैं
तब इश्यू बंद हो जाता है

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

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

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

1. हमारे परीक्षण के तरीके (बल्कि टेस्ट एपीआई, @ Test एनोटेशन वाले लोगों की तुलना में) उन जटिल मूल्यों / वस्तुओं (मानचित्र) को स्वीकार करते हैं जो नियमित अभिव्यक्ति का उपयोग करके सादे पाठ और पार्स में लिखना मुश्किल है।
2. उदाहरण के लिए, परीक्षण विधियाँ लौटती हैं और चर का उपयोग करती हैं, उदाहरण के लिए, बनाई गई संस्थाओं की प्राथमिक कुंजी लौटें, फिर इस पीके का उपयोग अन्य विधियों में किया जाता है। और यद्यपि "चर" के लिए समर्थन एक सरल पाठ भाषा में संभव है, यह अभी भी असुविधाजनक है और एक बड़ा ऋण है।
3. हम अभिव्यक्ति को चर के रूप में उपयोग करते हैं। उदाहरण के लिए, विभिन्न बिल्डरों ने "अंतिम रविवार" या "अगले सोमवार" की तारीख निर्धारित की। वैसे, हम जहां भी संभव हो, मनमाना / यादृच्छिक परीक्षण डेटा उत्पन्न करते हैं, और हम उन पर आधारित सभी जांच करते हैं, इसलिए हम अक्सर अभिव्यक्ति और चर का उपयोग करते हैं।
4. प्रसंग। हमारे पास अधिकांश क्रियाएं वर्तमान उपयोगकर्ता सत्र से जुड़ी हैं। जब दो समानांतर सत्र बनाना आवश्यक था, तो इससे कोई समस्या नहीं हुई। ककड़ी के मामले में, पूरी तरह से नए वाक्यांशों / विधियों को अलग करना आवश्यक होगा जो सत्र के संकेत के साथ और बिना काम करेंगे।
5. डेटा जाँच। ऐसा करने के लिए, हम हैमरेस्ट का उपयोग करते हैं, और केवल कुछ मिलानकर्ताओं के साथ, हम विविध और कठिन परिस्थितियों का एक गुच्छा रिकॉर्ड कर सकते हैं। ककड़ी के साथ, इसके लिए आपको मिलानकर्ताओं के प्रत्येक संयोजन के लिए कोड की एक पंक्ति के साथ अलग-अलग तरीकों का चयन करना होगा। और सबसे खराब स्थिति में, मिलानकर्ताओं और परीक्षण मूल्य के प्रत्येक संयोजन के लिए एक विधि।
6. पुनर्रचना। मैं कोड की तुलना में बहुत अधिक परीक्षणों को रिफ्लेक्टर करता हूं, (ठीक है, यह पता चला है) और आईडीई मुझे इसमें बहुत मदद करता है, काफी जटिल क्रियाओं को स्वचालित करता है। एक साधारण पाठ भाषा को कैसे रिफैक्ट करें? और अगर एक विधि हुआ करती थी, तो क्या होगा और फिर कोड बदल गया और आपको इसे अलग-अलग चर या अलग-अलग नामों से दो तरीकों में विभाजित करना होगा। क्या यह सरल-पाठ कोड के पूरे आधार पर स्वचालित रूप से करना संभव है?

ककड़ी के साथ सरल-पाठ स्क्रिप्ट विकसित करने के प्रयास को बर्बाद करने के बजाय, हम उन्हें जावा (बाकी परियोजना की तरह) में लिखते हैं और कोड "स्वच्छ" और पठनीय रखने पर प्रयास खर्च करते हैं।

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

व्यवहार के उपरोक्त विवरण के अनुरूप कोड उदाहरण पर विचार करें:

 String issueId = issueHelper().createIssue(); List bugIds = new ArrayList(); int numberOfBugs = Random.getNumberBetween(1, 5); while(numberOfBugs>0){ bugIds.add(issueHelper().createBug(issueId)); numberOfBugs--; } for(String bugId : bugIds){ navigator().goto(bugId); workflowHelper().doAction("fixed"); } navigator().goto(issueId); assertThat(getField("status"),is("Closed")); 

परीक्षण चलाते समय, यह कोड निम्नलिखित प्रदर्शित करता है:

मनमाने मापदंडों के साथ समस्या बनाएँ (नए मुद्दे की कुंजी HR-17)
एचआर -17 मुद्दे पर बग बनाएं (नए बीजी -26 बग की कुंजी)
एचआर -17 मुद्दे पर बग बनाएं (नए बीजी -27 बग की कुंजी)
पेज पर जाएं प्रमुख बीजी -26
निश्चित कार्रवाई करें
पृष्ठ पर जाएं प्रमुख BG-27 के साथ
निश्चित कार्रवाई करें
एचआर -17 कुंजी पृष्ठ पर जाएं
जांचें कि स्थिति का मान "बंद" फ़ील्ड है।

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

इसलिए, हमें "बीडीडी वाइस वर्सा" मिलता है।

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

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

1. यह परीक्षण कोड की गुणवत्ता में बहुत सुधार करता है। सच, बहुत।
   लेकिन केवल अगर आप विधि कॉल के विवरण को लॉग करते हैं, और आउटपुट को मजबूर नहीं करते हैं: log("I did something") । फिर आपको उन तरीकों का चयन करना होगा जो व्यावसायिक अवधारणाओं के अनुरूप हैं, और फिर, आप देखते हैं, कोड को कम दोहराया गया है और यह बेहतर संरचित है। और एक विश्लेषक इसका अनुसरण कर सकता है, बिना प्रोग्रामिंग अनुभव के, कौन कहेगा - आपका कोड व्यावसायिक अवधारणाओं पर काम करता है, या कुछ अजीब बटन क्लिक करता है, अर्थात। इंटरफ़ेस चेकमार्क के निचले स्तर पर कहीं लुढ़का हुआ है। तदनुसार, परीक्षण छोटे और अधिक समझने योग्य हैं।
2. यह आपको समझने की अनुमति देता है कि परीक्षण "क्यों गिर गया।"
   इसके अलावा, हम पहले स्तर के तरीकों के लिए कॉल के रूप में लॉग इन कर सकते हैं, अर्थात्। उन लोगों को परीक्षण स्क्रिप्ट में लिखा गया है, साथ ही आंतरिक तरीकों से भी कॉल किया गया है। और न केवल कॉल करता है, बल्कि सभी मापदंडों और लौटे मूल्यों के साथ।
3. कभी-कभी यह समझना आसान होता है कि परीक्षण क्या करता है यह जानने के लिए कोड की तुलना में लॉग को समझना होगा।
   मैं खुद इससे हैरान हूं, जैसे कोशिश करना, खूबसूरती से लिखना, रिफ़ेक्ट करना, लेकिन फिर भी, कुछ समय बाद कोड स्पष्ट नहीं है, और "रूसी" लॉग मदद करता है। ठीक है, इसका मतलब है कि कोड की कोशिश करने और सुधार करने के लिए अभी भी जगह है। कभी-कभी, वैसे, यह बीडीडी विवरण को देखने में मदद करता है, जिसे हम प्रत्येक परीक्षा के लिए एनोटेशन में बोर्ड से फिर से लिखते हैं। ये विवरण परीक्षण रिपोर्ट में जाते हैं क्योंकि वे अभी भी अधिक कॉम्पैक्ट और समझने योग्य हैं। यह एक बार फिर मुझे आश्वस्त करता है कि इस तरह के विवरण और परीक्षण स्क्रिप्ट को अलग करना सही था।
4. यह आपको परीक्षण एपीआई में जावाडॉक लिखने के लिए मजबूर करता है, कम से कम कुछ। और यह बदले में, परीक्षणों के लेखन को सरल करता है, खासकर अगर एक से अधिक व्यक्ति उन्हें लिखते हैं। दिलचस्प है, और ucumber का उपयोग करते समय, क्या Ctrl + space बार मापदंडों के विवरण के साथ उपलब्ध तरीकों के संकेत प्राप्त कर सकता है? <Ctrl + Space> के पास गया
5. आप पहलू ओरिएंटेड प्रोग्रामिंग को विचलित और तलाश सकते हैं। भविष्य के लिए एक विचार के रूप में: मैं यह सुनिश्चित करना चाहता हूं कि जब आप doSomething(getSomething()) , doSomething() लॉग को केवल getSomething() विधि (उदाहरण के लिए, 5) के परिणाम के लिए प्रतिस्थापित किया जाता है, लेकिन getSomething() के विवरण के साथ getSomething() विधि। यह स्पष्ट है कि इस परिणाम (5) का मतलब क्या है और यह कहां से आया है। मुझे यह सुनिश्चित करना होगा कि जब, एक बार फिर, "मैं सब कुछ बीमार हूँ"।

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

इस कल्पित कहानी का नैतिक यह है: प्रयोग, परीक्षण लिखना, और आपकी मदद करने के लिए एक लॉग।