Cucumber-js: मैं प्रत्येक फीचर फ़ाइल के लिए चरण परिभाषा फ़ाइल कैसे निर्दिष्ट कर सकता हूं?

को निर्मित 2 फ़र॰ 2017 · 18टिप्पणियाँ · स्रोत: cucumber/cucumber-js

मेरा लक्ष्य

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

मेरा कोड

मैं अपना वर्तमान उदाहरण दिखाता हूं:

मेरी फ़ोल्डर संरचना:

/features/sample.feature
/features/example.feature
/features/step_definitions/sample_steps.js
/features/step_definitions/example_steps.js
/features/step_definitions/common/common_steps.js

मेरे sample.feature में मेरे पास है:

  Scenario: Launching Cucumber
  Given I have some step definitions
   When I check some step definition with parameter "any"
   Then I should see all green "sample"

मेरे example.feature में मेरे पास है:

  Scenario: Launching Cucumber
  Given I have some step definitions
   When I check some step definition with parameter "any"
   Then I should see all green "example"

Given और When चरणों को /common/common_steps.js फ़ाइल में परिभाषित किया गया है और यह ठीक काम करता है।

Then चरण को sample_steps.js और example_steps.js दोनों के लिए परिभाषित किया गया है लेकिन अलग-अलग।

मेरे sample_steps.js में मेरे पास है:

Then('I should see all green {stringInDoubleQuotes}', (arg) => {
   if (arg !== 'sample') {
     throw 'I should see all green when the argument is "sample"';
   }
   return;
 });

और, अंत में, मेरे example_steps.js में मेरे पास है:

Then('I should see all green {stringInDoubleQuotes}', (arg) => {
   if (arg !== 'example') {
     throw 'I should see all green when the argument is "example"';
   }
   return;
 });

त्रुटि

मेरा मुख्य लक्ष्य यहां सभी हरे रंग का होना है, लेकिन निश्चित रूप से, यह काम नहीं करता है और मुझे यह स्पष्ट त्रुटि मिलती है:

Multiple step definitions match:
   I should see all green {stringInDoubleQuotes} - features\step_definitions\example_steps.js:6
   I should see all green {stringInDoubleQuotes} - features\step_definitions\sample_steps.js:6

ककड़ी-जेवीएम

मुझे पता है कि ककड़ी-जेवीएम में हम एक glue विशेषता निर्दिष्ट कर सकते हैं जो सुविधाओं और step_definitions को जोड़ता है और यह वही है जो मैं ढूंढ रहा हूं, लेकिन ककड़ी-जेएस में। जावा में उदाहरण:

@RunWith(Cucumber.class)
@Cucumber.Options( glue = { "com.app.stepdefinitions.common", "com.app.stepdefinitions.sample" } )
public class SampleFeature{
}

@RunWith(Cucumber.class)
@Cucumber.Options( glue = { "com.app.stepdefinitions.common", "com.app.stepdefinitions.example" } )
public class ExampleFeature{
}

आखिरकार

मैं ककड़ी-जेवीएम का उपयोग करके ककड़ी-जेवीएम के समान कैसे प्राप्त कर सकता हूं?

स्रोत

robsonrosa

👍14 🎉9 ❤4

सबसे उपयोगी टिप्पणी

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

मेरी कंपनी में, हमारे उत्पाद में सैकड़ों विशेषताएं हैं और क्यूए में 100k रेंज में परीक्षण मामले हैं।
यदि हम cucumber का उपयोग करते हैं तो हम निश्चित रूप से इस समस्या में भाग लेंगे।

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

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

फ़ीचर/परिदृश्य पहले से ही परिभाषा के अनुसार संदर्भ प्रदान करते हैं, इसलिए गेरकिन सिंटैक्स में इंडेंटेशन है।

टैग और कस्टम डीएसएल जोड़ना समाधान के बजाय कार्यान्वयन सीमा (यानी एक हैक, आईएमओ) का समाधान है।

हो सकता है कि आप https://github.com/cucumber/cucumber-js/issues/745 पर विचार करते हुए इस पर विचार कर सकते हैं?

Scenario को defineStep $ से बढ़ाने और कॉलबैक में {Given, When, Then} पास करने के बारे में कैसे?

अर्थात:

import {defineSupportCode} from 'cucumber'

defineSupportCode(({ Scenario, Given, When, Then }) => {
  Given(...)
  When(...)
  Then(...)
  Scenario('<match scenario description>', ({ Given, When, Then}) => {
    Given('<take precedent of non-contexted>', ...)
    ...
  })
})

unional 23 मार्च 2017

👍11 ❤1

सभी 18 टिप्पणियाँ

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

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

charlierudolph 4 फ़र॰ 2017

👍1

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

Given [comp1] I click on "Open dialog"

बनाम

Given [comp2] I click on "Open dialog"

यह हमें अस्पष्ट चरण परिभाषाओं से बचने में मदद करता है, लेकिन वास्तव में अपठनीय फीचर फाइलों की ओर जाता है।
मैंने ककड़ी.जेएस स्रोत के साथ छेड़छाड़ करने की कोशिश की, लेकिन इस सुविधा के लिए समर्थन जोड़ने के लिए कोई अच्छा संकेत नहीं मिला।

क्या इसे कुछ हुक या वैकल्पिक दुनिया के साथ महसूस किया जा सकता है?

leipert 10 फ़र॰ 2017

👍1

@leipert आप किस यूजर इंटरफेस की कल्पना कर रहे हैं? मेरा मानना है कि इस तर्क को दुनिया में रहना चाहिए या कई विश्व वस्तुओं का समर्थन करना चाहिए। फिर चरण परिभाषाएं केवल गेरकिन मैचों को पार्स करने और उन्हें उचित विश्व फ़ंक्शन में पास करने से निपटती हैं। हम किस विश्व वस्तु का उपयोग करने के लिए चयन करने के लिए एक सीएलआई विकल्प जोड़ सकते हैं।

फिलहाल यदि आप कई दुनिया/चरण परिभाषाएं रखना चाहते हैं तो आप इसे अलग-अलग फ़ोल्डरों में अपना कोड डालकर प्राप्त कर सकते हैं और केवल उनमें से एक प्रति रन की आवश्यकता होती है ( --require CLI विकल्प का उपयोग करके)।

charlierudolph 14 फ़र॰ 2017

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

cucuber.js में अभी तक केवल टैग ही आपके उद्देश्य के करीब हैं। लेकिन केवल हुक ही घोषणा कर सकते हैं कि वे टैग के लिए विशिष्ट हैं। यदि आप सुनिश्चित हैं कि यह आपके लोगों के लिए सही तरीका है, तो आप एक डीएसएल का आविष्कार कर सकते हैं, शायद चरण पैटर्न में [फीचर नाम] के रूप में सरल।

pinxue 16 फ़र॰ 2017

👍3

धन्यवाद, @pinxue । बहुत उपयोगी प्रतिक्रिया। हालाँकि, मैं इसे नहीं समझ सकता:

खैर, "ककड़ी पुस्तक" विशेष रूप से चरणों को डिजाइन करने के इस तरीके को हतोत्साहित करती है।

एक ही क्रिया वाक्यांश के अलग-अलग संदर्भों में अलग-अलग अर्थ हो सकते हैं। लेकिन यह ठीक है। मेरे पास विकल्पों को जानना अच्छा है, वास्तव में, हम इसे प्राप्त करने के लिए पहले से ही एक आंतरिक डीएसएल पर चल रहे हैं,

बहुत - बहुत धन्यवाद।

robsonrosa 17 फ़र॰ 2017

आपके उत्तर @pinxue और @robsonrosa के लिए धन्यवाद।
स्कोप्ड चरण परिभाषाओं के लिए मेरा तर्क यहां दिया गया है:

_वैश्विक चर खराब हैं और पैमाने पर नहीं हैं_:
हमारे पास लगभग 15 फीचर फाइल फाइलें हैं जिनमें से प्रत्येक में 10 परिदृश्य हैं, और सभी चरण परिभाषाओं और फीचर फाइलों की संरचना करना पहले से ही कठिन है। बड़े अनुप्रयोगों के लिए (उदाहरण के लिए, 5 चरणों के औसत के साथ 10 परिदृश्यों के साथ 100 फीचर फाइलें) विश्व स्तर पर परिभाषित सभी चरणों को पागल लगता है, क्योंकि यह ट्रैक करना वास्तव में कठिन है कि कौन सी फीचर फाइल किन चरणों का उपयोग करती है।
_डेवलपर्स का फीचर फाइलों में शब्दों पर कोई नियंत्रण नहीं है_:
हमारे उपयोग के मामले में हमारा "प्रबंधन" फीचर फाइलें लिखता है, उन्हें बेचना मुश्किल है: हम शानदार बीडीडी करते हैं, लेकिन आपको खुद को एक अजीब कस्टम डीएसएल तक सीमित करना होगा।
_अगर ककड़ी-जेवीएम के पास विकल्प है, तो ककड़ी-जेवीएम के पास क्यों नहीं?_
यह एक बुरा तर्क हो सकता है

मैं हमारे लिए समस्या को हल करने के लिए निम्नलिखित दृष्टिकोण देखता हूं:

चरण परिभाषाओं में उपसर्गों के साथ एक कस्टम डीएसएल बनाएं
विपक्ष: साथ काम करना अच्छा नहीं है।
पेशेवरों: ककड़ी में कोई बदलाव की जरूरत नहीं है। जेएस
ककड़ी के लिए glue बनाएं।js
विपक्ष: "द ककड़ी बुक" के विचार के खिलाफ जा सकते हैं।
पेशेवरों: cucumber.js के साथ फ़ीचर समानता
बदलें कि हम परीक्षण कैसे चलाते हैं
विपक्ष: यह सुविधा कम लोगों को मिलेगी।
पेशेवरों: ककड़ी में कोई बदलाव की जरूरत नहीं है। जेएस

कहा जा रहा है, हम शायद 3 के साथ जाएंगे, अगर ककड़ी के अनुरक्षकों को लगता है कि इस परियोजना के लिए स्कोप्ड चरण परिभाषाएं दायरे से बाहर हैं (सजा का इरादा)।

एक बार आपके पास होने के बाद, @robsonrosa मुझे आपके समाधान में दिलचस्पी होगी।

leipert 20 फ़र॰ 2017

👍6

हो सकता है कि आप https://github.com/cucumber/cucumber-js/issues/745 पर विचार करते हुए इस पर विचार कर सकते हैं?

Scenario को defineStep $ से बढ़ाने और कॉलबैक में {Given, When, Then} पास करने के बारे में कैसे?

अर्थात:

import {defineSupportCode} from 'cucumber'

defineSupportCode(({ Scenario, Given, When, Then }) => {
  Given(...)
  When(...)
  Then(...)
  Scenario('<match scenario description>', ({ Given, When, Then}) => {
    Given('<take precedent of non-contexted>', ...)
    ...
  })
})

unional 23 मार्च 2017

👍11 ❤1

मैं http://fitnesse.org/ से बीडीडी सीखता हूं, इसलिए मैं बीडीडी को ककड़ी समुदाय की तुलना में अलग तरीके से देख सकता हूं।

unional 23 मार्च 2017

पेजिंग @richardlawrence

mattwynne 23 मार्च 2017

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

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

richardlawrence 23 मार्च 2017

👍5 😕1

ककड़ी के साथ काम करने और सीमाएँ बनाने के बारे में एक लेख। यह इस पृष्ठ पर कुछ विचारों को लागू करता है लेकिन कोई महान समाधान प्रस्तुत नहीं करता है क्योंकि @richardlawrence ने उल्लेख किया है कि आप चरण परिभाषाओं के लिए एक विशेष वर्ग पर ध्यान केंद्रित करने के लिए ककड़ी को कॉन्फ़िगर नहीं कर सकते हैं। http://confessionsofanagilecoach.blogspot.com/2017/05/teaching-cucumbers-about-boundaries.html

lancerkind 2 मई 2017

👍1

जैसा कि @leipert ने कहा, वैश्विक चर खराब हैं। मुझे लगता है कि CucumberJVM दुनिया में हम में से केवल आधी कहानी ही प्राप्त कर रहे हैं। ककड़ी (गैर जेवीएम) एक सुव्यवस्थित विश्व अवधारणा का उपयोग करता है जो परिदृश्य की अवधि के लिए एक वैश्विक स्मृति स्थान है। परिदृश्य निष्पादित होने के बाद, इसे नष्ट कर दिया जाता है। यह एक अच्छा समाधान लगता है। लेकिन... मुझे CucumberJVM में इस पैटर्न का अच्छा कार्यान्वयन नहीं दिख रहा है। तो अगर ककड़ी हमें कदम परिभाषाओं के लिए एक फ्लैट/वैश्विक नामस्थान रखने के लिए मजबूर करती है, और विश्व पैटर्न को लागू करने के लिए ककड़ीजेवीएम के पास एक स्पष्ट डिजाइन पैटर्न था, तो मैं थोड़ा खुश हूं। इस बिंदु तक, CucumberJVM + World pattern == अत्यधिक जटिल समाधान। अब तक, मैंने जो कुछ भी देखा है, वह मुझे यह नियंत्रित करने की तुलना में अधिक जटिल है कि कौन से चरण फ़ंक्शन किस फीचर फ़ाइल के साथ चलते हैं। अब तक मैंने जो विकल्प देखे हैं, वे मुझे सभी प्रयासों/जटिलता के लिए और अधिक मूल्यवान नहीं देते हैं। अन्य प्रकार के ककड़ी में बेहतर विश्व समाधान होते हैं।

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

lancerkind 4 मई 2017

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

eliezercazares 7 अप्रैल 2018

मैं आपका लक्ष्य समझता हूं, लेकिन मैं इसकी अनुशंसा नहीं करूंगा।
मैं स्पष्ट .feature फ़ाइलों को रखने की भी अनुशंसा करता हूं, या तो पृष्ठभूमि विवरण या एक अतिरिक्त दिए गए चरण के साथ जो इसे स्पष्ट करता है।

वैकल्पिक रूप से आप दो अलग-अलग कॉन्फ़िगरेशन फ़ाइलें बना सकते हैं।
एक नमूने के लिए और दूसरा उदाहरण के लिए।
फिर आप अलग-अलग स्टेप फोल्डर की ओर इशारा कर सकते हैं।

andreasmarkussen 9 अप्रैल 2018

@robsonrosa @leipert मैं आपकी राय साझा करता हूं
मूल पोस्ट के लगभग दो साल बाद ...
क्या आपको इससे कोई प्रगति मिली? कोई उपाय?

cristianmercado19 10 जन॰ 2019

@ cristianmercado19 क्षमा करें, नहीं। मैं अब ककड़ी जेएस का उपयोग नहीं कर रहा हूं।

leipert 10 जन॰ 2019

Ups... मुझे फीचर फ़ाइल लिखने का तरीका पसंद है जो स्टेप के कार्यान्वयन से पूरी तरह से अलग है।
मैंने उसी लक्ष्य को _मोचा_ के साथ हासिल करने की कोशिश की है लेकिन मैं इससे खुश नहीं हूं।
यदि आपके पास कोई अन्य विकल्प है जो मेरे लक्ष्य को पूरा करता है, तो कोशिश करने से ज्यादा खुशी होगी।
आपकी मदद @leipert की सराहना करें।

cristianmercado19 10 जन॰ 2019

इस थ्रेड को स्वचालित रूप से लॉक कर दिया गया है क्योंकि इसे बंद करने के बाद हाल ही में कोई गतिविधि नहीं हुई है। कृपया संबंधित बग के लिए एक नया मुद्दा खोलें।

lock[bot] 10 जन॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Cucumber-js: मैं प्रत्येक फीचर फ़ाइल के लिए चरण परिभाषा फ़ाइल कैसे निर्दिष्ट कर सकता हूं?

मेरा लक्ष्य

मेरा कोड

त्रुटि

ककड़ी-जेवीएम

आखिरकार

सबसे उपयोगी टिप्पणी

सभी 18 टिप्पणियाँ

संबंधित मुद्दों