Same step twice in a scenario confuses Eclipse's JUnit runner

[gisode]

JUnit associates an instance of its Description class with each test method (which correspond to steps in cucumber). The Description instance of a test method/step mainly contains a label for the test method/step when JUnit and the various runners out there want to represent it visually.

Unfortunately, JUnit also uses the Description as a key to keep track of the state of test methods, i.e. whether they have run, failed, were ignored and so on. Thus, each test method/cucumber step must have an associated Description that is not Java-equal to any other Description in the whole Suite. Otherwise runners will get confused and report on the wrong steps.

Even more unfortunately, Descriptions are Java-equal when the labels contained within them are Java-equal. It follows that even with the current implementation of cucumber's ExecutionUnitRunner.describeChild() method, when a step occurs twice in the same scenario, the two corresponding Description instances will be Java-equal.

I see two ways to proceed here:

• Have the JUnit guys merge a fix that is compatible with their idea of a solution (see comments on https://github.com/KentBeck/junit/pull/184)
• Modify the ExecutionUnitRunner.describeChild() method so that it also includes in the Description of each step, say, the index in the list of steps within the scenario where the step occurs. The scenario name is already part of the Description (within the parentheses), so the step number should not look too ugly.

I'm going to have a look at the second option on Monday. From a glance at the code it seems finding the index of a step within a scenario should be a one-liner.

If you cucumber guys are ok with that approach, I will see if I can fix it that way and provide a pull request for it.

[aslakhellesoy]

Great analysis! I think the short term solution is to work around JUnit in Cucumber-JVM. Perhaps just prepending a counter. That will look a bit ugly, but it seems to be the only option for junit 4.10 and older.

When a new JUnit is out with a fix for this, we should keep the short term solution as well, so that people who happen to be on an older junit can still have this working. We could decide at runtime whether to use the workaround or not.

Thanks for looking into this. If you create a junit ticket/pullreq, please link to this so they get the context.

[aslakhellesoy]

Fixed by #216

[lock]

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.