Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to organize the specs definition in Cucumber?
    primarykey
    data
    text
    <p>We are considering to use <strong>Cucumber</strong> on our project for acceptance testing.</p> <p>When we write a <code>scenario</code> in a Cucumber <code>feature</code>, we write a list of <code>Given</code>, <code>When</code> and <code>Then</code> statements.</p> <p>As we use <a href="https://github.com/cucumber/cucumber-jvm" rel="noreferrer">cucumber-jvm</a> project, the <code>Given</code>, <code>When</code> and <code>Then</code> statement are related to Java methods in (JUnit) classes.</p> <p>I want to know what is the best organization for the code related to <code>Given</code> / <code>When</code> / <code>Then</code> in the project structure. My main concern is the maintenance of the cucumber tests on a big project, where the number of scenario is quite important, and especially regarding the items that are shared between features.</p> <p>I can see at least 2 main approaches:</p> <ol> <li><p>Each feature is related to it's own JUnit class. So if I have a <code>foo/bar/baz.feature</code> cucumber file, I will find the releated <code>foo.bar.Baz</code> JUnit class with the adequate <code>@Given</code>, <code>@When</code> and <code>@Then</code> annotated methods.</p></li> <li><p>Separate <code>@Given</code>, <code>@When</code> and <code>@Then</code> methods into "thematic" classes and packages. For example, if in my cucumber scenario I have a statement <code>Given user "foo" is logged</code>, then the <code>@Given("^user \"([^\"]*)\" is logged$")</code> annotated method will be located in the <code>foo.user.User</code> class method, but potentially, the <code>@When</code> method used later in the same cucumber scenario will be in a different Java class and package (let say <code>foo.car.RentCar</code>).</p></li> </ol> <p>For me, the first approach seems good in the way that I can easily do the relation between my cucumber features and my Java code. But the drawback is that I can have a lot of redundancies or code duplication. Also, it may be hard to find a possible existing <code>@Given</code> method, to avoid to recreate it (the IDE can help, but here we are using Eclipse, and it does not seem to give a list of existing <code>Given</code> statement?).</p> <p>The other approach <em>seems</em> better essentially when you have <code>Given</code> conditions shared among several cucumber feature, and thus I want to avoid code duplication. The drawback here is that it can be hard to make the link between the <code>@Given</code> Java method and the <code>Given</code> cucumber statement (maybe, again, the IDE can help?).</p> <p>I'm quite new to cucumber, so maybe that my question is not a good question, and with time and experience, the structure will be self-evident, but I want to get good feedbacks on its usage...</p> <p>Thanks.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload