Cucumber-jvm: Duplicate step definitions

[carlparziale]

When two Features have the same WHEN or THEN annotations, Cucumber JVM is finding collisions in the mappings. Assume it has to do with how Cucumber/Regex resolves to the correct methods to execute.

Since the Features were seperate files, and the Glue code where seperate Classes, was assuming this wouldn't conflict.

Any way to solve this, besides changing the feature files.

Error that is thrown:

Duplicate step definitions in cucumber.examples.java.helloworld.DummyName.I_ask_it_to_say_hi() in file:/C:/Users/nbk3wqf/workspaceJuno/java-helloworld/target/test-classes/ and cucumber.examples.java.helloworld.HelloCarlTestSteps.I_ask_it_to_say_hi() in file:/C:/Users/nbk3wqf/workspaceJuno/java-helloworld/target/test-classes/

Two separate Feature files:

Feature: Hello Carl
Scenario: Say hello Carl
Given I have a hello carlApp
When I ask it to say hi
Then it should answer with "Howdy World"

Feature: Hello World
Scenario: Say hello
Given I have a hello app with "Howdy"
When I ask it to say hi
Then it should answer with "Howdy World"

[aslakhellesoy]

Cucumber doesn't distinguish between Given/When/Then. It only matches based on the regexp. If two or more regexen match, Cucumber can't figure out which one to run. It doesn't matter if they are in different files - stepdefs are global.

This is by design. The rationale is to prevent users building up an ambiguous vocabulary. You have to change your wording to work around it.

[carlparziale]

Would like to make the arguement to modify this design point. Perhaps this is a Cucumber design point rather than Cucumber JVM so maybe this should be on a Cucumber site instead? Maybe this is the wrong place for this topic?

However, Here's my argument:
Features files are a natural container of a complete acceptance test scenario. The context of each sentence in that feature file only has context in the paragraph in which its contained. The Feature file forms a good boundry for that context. Additionally, State that is built up over the interpretation of a Feature file should only have contect for the life of that feature file interpretation event. Switching to the implementation, instance variables set in the GlueCode StepDef Java Class should be available for life of that file interpretation and only have context to steps in that file, and are available for the interpretation of all those sentences and only those.

Given all that, it would be nice if individual sentences (e.g. And, When, Then, Given) should only have to be unique in the context of a single Feature file and in the implementation, would be nice if the convention was a Glue Code StepDef Java Class file contained the state (as it does) and the context of the WHEN, THEN, GIVEN methods, once the Feature file is identified should be scoped to that class. If scoped to the Feature file- GlueCode class, this would eliminate the uniqueness requirement across entire test suite issue and also eliminate the risk of unintended issues of state variables not spanning classes, Today, a method implemented in one class, could use a variable not set in another class

This would limit some 'creatvivity' on test creation (reused sentences etc...), but give the Feature File a more natural language feel and reduce the barrier to write them by Product Owners vs Developers.

Is there some other forum I should make this case?

[aslakhellesoy]

Instance variables are available for the duration of the _scenario_ - not the _feature_. A new instance of each glue class is created before a scenario begins.

It sounds like what you want is this: https://github.com/cucumber/cucumber/wiki/Feature-Coupled-Step-Definitions-(Antipattern) - and for Cucumber to somehow only see _certain_ step definitions for any given feature file.

Every now and then, people on the mailing list revisit this topic and ask for it. It has been debated a lot, and so far nobody has succeded in convincing the majority that this is a good thing.

Please feel free to try that again on the mailing list ;-)

[carlparziale]

LOL tilting at windmills.....ok..thanks.

Carl

[carlparziale]

Aslak,
So i'm about to go over to the Cukes mailing list. I'll make a case and see where it gets me :). I have a working modified version of Cucumber JVM 1.0.014 that supports the concept I mentioned. In essense i created a Class level Annotation that can serve to scope the Glue (StepDef) class to a Feature file. This would than allow for identical worded steps to be used in different Feature files. If the Annotation is NOT specified the behavior is as it is today. In fact, if Steps are defined in a Non-Annocated Class, those steps are available to be reused from a Scoped Feature or not. So the 'reuse' of steps is possible (Stateless steps i'd suspect would only really apply?)

In essence the format would be:

@FeatureScope("cucumber\examples\java\helloworld\hellocarl.feature")
public class HelloCarlTestSteps {
}

If you're interested in the Source/demo, i'd be happy to send. I don't really know the rules for GitHub, so i wouldn't want to check in, also since its deviant behavior wouldn't want to pollute the streams. Anyway, if interested let me know.

..Carl

[aslakhellesoy]

Hi Carl. Please _fork_ cucumber-jvm, _clone your fork_ to your local machine, _commit_ your changes and _push_ them to your fork of the repo on github.

You don't have access to push changes to the official repo, so no worries there. Guidelines here: http://help.github.com/

Let's discuss the proposed change on the ML.

[carlparziale]

Hello Aslak,

I've pushed the modifications to the fork https://github.com/carlparziale/cucumber-jvm

There are about 7 changed files and 1 added file.

The protocol to use the new Annotation is as follows. (The double "" didn't carry above).
@FeatureScope("cucumber\examples\java\helloworld\hellocarl.feature")
public class HelloCarlTestSteps {
}

i have some local test Glue classes, but haven't posted them anywhere yet.

I'm going to venture into the Google Cukes mailing list and float the suggestion...see where it goes :)

[chrisdostert]

Very old thread, but did anything ever come of this? This is a fantastic enhancement. I prefer single purpose built FeatureStepDefs class for each feature that knows no more and no less than is needed to test the specific feature under test. If I need access to shared helpers I can simply use DI. The only way i've found to do this with current cucumber-jvm implementation is to use a package per feature and then explicitly supply that via @CucumberOptions(features = {"my.feature"},glue = {"mypackage"})

[dkowis]

Take discussion up on the mailing list please.

http://cucumber.io/support

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.