[cucumber-java] How to organise files
Miguel Almeida
As I understand, in cucumber-java you need a Some_Test class annotated with @Feature to tell cucumber where to find feature files. My question is: is one-class-per-feature the general approach?
This question links to a suggestion I read to organise your acceptance tests in two sets:
- current iteration
- hierarchy structure for past iterations
This means I'll be moving my feature files from current Iteration to hierarchy structure after they are finished, and also means we'll consequentially have to change every Some_Test class' @Feature annotation to point to the new location.
Is this the expected/usual workflow?
Cheers,
Miguel
aslak hellesoy
<migueld...@gmail.com> wrote:
> Dear all,
>
> As I understand, in cucumber-java you need a Some_Test class annotated with
> @Feature to tell cucumber where to find feature files.
You don't need a @Feature annotation if you name the JUnit class like
the feature file.
See Class Javadocs for @Cucumber:
https://github.com/cucumber/cucumber-jvm/blob/master/junit/src/main/java/cucumber/junit/Cucumber.java
> My question is: is
> one-class-per-feature the general approach?
>
It's currently the general approach if you're using JUnit to kick off Cucumber.
> This question links to a suggestion I read to organise your acceptance tests
> in two sets:
> - current iteration
> - hierarchy structure for past iterations
>
Where did you read this? Sounds dubious to me. I have never found a
need to do anything more sophisticated than tagging features with
@slow. Then I'll run all the not slow (--tags ~@slow) while
developing, and run them all before I push - and also in CI.
This workflow is a little cumbersome using the JUnit runner. The CLI
runner is better suited for this since you can pass --tags to it.
Aslak
> This means I'll be moving my feature files from current Iteration to
> hierarchy structure after they are finished, and also means we'll
> consequentially have to change every Some_Test class' @Feature annotation
> to point to the new location.
>
> Is this the expected/usual workflow?
>
> Cheers,
>
> Miguel
>
> --
> You received this message because you are subscribed to the Google Groups
> "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to
> cukes+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cukes?hl=en.
>
Miguel Almeida
On Wednesday, October 26, 2011 5:20:32 PM UTC+1, Aslak Hellesøy wrote:
On Wed, Oct 26, 2011 at 5:05 PM, Miguel Almeida
<migueld...@gmail.com> wrote:
> Dear all,
>
> As I understand, in cucumber-java you need a Some_Test class annotated with
> @Feature to tell cucumber where to find feature files.You don't need a @Feature annotation if you name the JUnit class like
the feature file.
See Class Javadocs for @Cucumber:
https://github.com/cucumber/cucumber-jvm/blob/master/junit/src/main/java/cucumber/junit/Cucumber.java> My question is: is
> one-class-per-feature the general approach?
>It's currently the general approach if you're using JUnit to kick off Cucumber.
> This question links to a suggestion I read to organise your acceptance tests
> in two sets:
> - current iteration
> - hierarchy structure for past iterations
>Where did you read this? Sounds dubious to me. I have never found a
need to do anything more sophisticated than tagging features with
@slow. Then I'll run all the not slow (--tags ~@slow) while
developing, and run them all before I push - and also in CI.
"If you work with a tool for automating executable specifications, it’s generally a good practice to group all them together for the work that’s currently in progress.";
"User stories are excellent as a planning tool, but they aren’t useful as a way to organize existing system functionality";
"Most teams reorganize their executable specifications into hierarchies by functional areas once they’ve been implemented. This makes it easy find an explanation of a feature by navigating through the hierarchy based on business functionality."
An example is shown of this with a project mindmap: completed features are organised by area (eg: payments-card processing - visa: {verified by visa; authorisation; refunds} ), while the current iteration is organised by stories ( Story #128: {gmail integration, age registration}).
This makes sense to me too in two ways: first, it allows us to quickly separate what our current work is from what is now essentially regression tests and documentation.
Secondly, it allows you to exclude "current iteration" from, say, your continuous integration: for the most part of the iteration you'll have failed tests there, and that would add noise to your CI feedback system: you'll want that to always be 100% "green".
Miguel
Richard Lawrence
I recommend organizing features to support long-term living
documentation and using tags to group scenarios around temporary
things like user stories or iterations. Reorganizing your features at
the end of every iteration just adds unnecessary work. Moreover, it's
useful to see new scenarios in the context of existing scenarios for a
larger feature.
Richard
>
>> This workflow is a little cumbersome using the JUnit runner. The CLI
>> runner is better suited for this since you can pass --tags to it.
>>
>> Aslak
>>
>> > This means I'll be moving my feature files from current Iteration to
>> > hierarchy structure after they are finished, and also means we'll
>> > consequentially have to change every Some_Test class' @Feature
>> > annotation
>> > to point to the new location.
>> >
>> > Is this the expected/usual workflow?
>> >
>> > Cheers,
>> >
>> > Miguel
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Cukes" group.
>> > To post to this group, send email to cu...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > cukes+un...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/cukes?hl=en.
>> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Cukes" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/cukes/-/GYhra1TODBsJ.
Miguel Almeida
On Thursday, October 27, 2011 5:07:38 PM UTC+1, Richard Lawrence wrote:
I recommend organizing features to support long-term living
documentation and using tags to group scenarios around temporary
things like user stories or iterations. Reorganizing your features at
the end of every iteration just adds unnecessary work. Moreover, it's
useful to see new scenarios in the context of existing scenarios for a
larger feature.Richard
- Junit in the IDE - either running a single test, a package, or the whole test set with Maven
- Run all tests in CI (Jenkins, running a maven goal)
Because I've never used tags, I'm not sure how they would apply in cucumber-jvm to achieve the desired goal. In understand tag usage to inlcude/exclude @Before and @After methods, but not in this case. You'd tag your feature with, say, @currentIteration. But how do you use that to filter out the current iteration in your mature tests (or to filter in just the current iteration)?
Miguel
Richard Lawrence
I recall Aslak saying you'd have to use the CLI runner in cucumber-jvm
to filter by tag. In Ruby Cucumber, you'd run
cucumber --tags @currentiteration
to run just scenarios with that tag. I imagine there's something
similar for cucumber-jvm.
Richard
> --
> You received this message because you are subscribed to the Google Groups
> "Cukes" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/cukes/-/tW91P9h3FWYJ.
Miguel Almeida
On Wednesday, October 26, 2011 5:20:32 PM UTC+1, Aslak Hellesøy wrote:
Where did you read this? Sounds dubious to me. I have never found a
need to do anything more sophisticated than tagging features with
@slow. Then I'll run all the not slow (--tags ~@slow) while
developing, and run them all before I push - and also in CI.This workflow is a little cumbersome using the JUnit runner. The CLI
runner is better suited for this since you can pass --tags to it.
Aslak
- If you use maven (both locally developers and in CI) to run your tests, you won't have a way to filter anything out. Have you thought about that problem?
(also, if you could have a look at yesterday's post on how to run from CLI it'd be great!)
Cheers,
Miguel Almeida
aslak hellesoy
<migueld...@gmail.com> wrote:
>
>
> On Wednesday, October 26, 2011 5:20:32 PM UTC+1, Aslak Hellesøy wrote:
>>
>> Where did you read this? Sounds dubious to me. I have never found a
>> need to do anything more sophisticated than tagging features with
>> @slow. Then I'll run all the not slow (--tags ~@slow) while
>> developing, and run them all before I push - and also in CI.
>>
>> This workflow is a little cumbersome using the JUnit runner. The CLI
>> runner is better suited for this since you can pass --tags to it.
>>
>> Aslak
>
> How do you manage features that haven't been implemented yet, Aslak? ie, if
> at the start of the iteration you make the features for it, I anticipate a
> problem (at least in our current configuration):
>
> - If you use maven (both locally developers and in CI) to run your tests,
> you won't have a way to filter anything out. Have you thought about that
> problem?
>
https://github.com/cucumber/cucumber-jvm/issues/83
> (also, if you could have a look at yesterday's post on how to run from CLI
> it'd be great!)
>
> Cheers,
>
> Miguel Almeida
>
> --
> You received this message because you are subscribed to the Google Groups
> "Cukes" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/cukes/-/Yi4ImZhn48AJ.