ककड़ी में चश्मा परिभाषा को व्यवस्थित करने के लिए कैसे?

Question

हम स्वीकृति परीक्षण के लिए हमारी परियोजना पर ककड़ी का उपयोग करने पर विचार कर रहे हैं।

जब हम एक ककड़ी feature में एक scenario लिखते हैं, हम Given, When और Then बयान की एक सूची लिखें।

हम cucumber-jvm परियोजना का उपयोग के रूप में, Given, When और Then बयान (JUnit) कक्षाओं में जावा तरीकों से संबंधित हैं।

मैं जानना चाहता हूं कि परियोजना संरचना में Given/When/Then से संबंधित कोड के लिए सबसे अच्छा संगठन क्या है। मेरी मुख्य चिंता एक बड़ी परियोजना पर ककड़ी परीक्षणों का रखरखाव है, जहां परिदृश्य की संख्या काफी महत्वपूर्ण है, और खासकर सुविधाओं के बीच साझा की जाने वाली वस्तुओं के बारे में।

1. प्रत्येक सुविधा अपने आप JUnit वर्ग से संबंधित है:

   मैं कम से कम 2 मुख्य दृष्टिकोण देख सकते हैं। तो अगर मेरे पास foo/bar/baz.feature ककड़ी फ़ाइल है, तो मुझे foo.bar.Baz जुनीट क्लास को @Given, @When और @Then एनोटेटेड विधियों के साथ रिलीज़ किया जाएगा।

2. पृथक @Given, @When और @Then "विषयगत" वर्गों और पैकेजों में विधियों। उदाहरण के लिए, यदि मेरे ककड़ी परिदृश्य में मेरे पास Given user "foo" is logged है, तो @Given("^user \"([^\"]*)\" is logged$") एनोटेटेड विधि foo.user.User कक्षा विधि में स्थित होगी, लेकिन संभावित रूप से, @When उसी ककड़ी परिदृश्य में बाद में उपयोग की जाने वाली विधि एक अलग जावा क्लास और पैकेज में होगी (foo.car.RentCar कहें)।

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

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

मैं ककड़ी के लिए काफी नया हूं, इसलिए शायद मेरा प्रश्न एक अच्छा सवाल नहीं है, और समय और अनुभव के साथ, संरचना स्वयं स्पष्ट होगी, लेकिन मैं इसके उपयोग पर अच्छी प्रतिक्रिया प्राप्त करना चाहता हूं ...

धन्यवाद।

Answer 1

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

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

इस बीच में यहाँ, ककड़ी के लिए एक ग्रहण प्लगइन है

https://github.com/matthewpietal/Eclipse-Plugin-for-Cucumber

यह वाक्य रचना हाइलाइटिंग के साथ ही मौजूदा उपलब्ध चरणों जब एक फीचर लेखन की एक सूची है।

Answer 2

मैं आपके कोड को आपके द्वारा प्रस्तुत किए गए विकल्प # 2 के समान, आपके द्वारा संदर्भित वस्तुओं के अनुसार आपके कोड को समूहीकृत करने का सुझाव देगा। कारण:

• इस कोड के आधार पर आपके कोड को संरचित करना कितना और कहां उपयोग किया जा रहा है, यह एक बड़ा नंबर नहीं है। यह वास्तव में आपकी फीचर फाइलों और आपके कोड के बीच युग्मन बना रहा है।
  अपने उत्पाद के कोड में ऐसी चीज की कल्पना करें- SendEmail() फ़ंक्शन NewEmailScreenCommands नामक कक्षा में नहीं होगा, है ना? यह EmailActions या कुछ ऐसे में होगा।
  तो यह वही लागू होता है; अपने कोड को इसके अनुसार बनाएं, और इसका उपयोग कौन नहीं करता है।

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

• विषय द्वारा समूहित कोड को रखना इसे बहुत आसान बनाता है; आप जानते हैं कि user इकाई से निपटने वाले सभी कोड कहां हैं, इसलिए आपके लिए इसका पुन: उपयोग करना आसान है।

हमारी परियोजना पर हम, कि दृष्टिकोण (यानी BlogPostStepDefinitions वर्ग) का उपयोग आगे कोड को अलग करने, वर्ग, बहुत बड़ा हो जाता है, तो कदम के प्रकार (यानी BlogPostGivenStepDefinitions) के साथ।

Answer 3

वर्तमान परियोजना में मैं भाग ले रहा हूं, हमने खुद को एक ही सवाल पूछा।

संभावनाओं के साथ थोड़ा सा झुकाव करने के बाद, हमने जो समाधान चुना है, वह दोनों समाधानों का मिश्रण था।

• चरणों विषय केंद्रित आम कदम कक्षाएं में फिर से एकजुट है
  • एप्लिकेशन शुरू कदम
  • सुरक्षा जांच कदम
  • [जगह यादृच्छिक सुविधा चिंता यहाँ] कदम
• और कक्षाएं परिदृश्य (और कुछ मामलों में भी सुविधा) विशिष्ट चरणों

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

इन सभी वर्गों के बीच तारों को वसंत द्वारा नियंत्रित किया जाता है (ककड़ी वसंत के साथ जो आपको लटकने के बाद एक महान काम करता है)।