Throw exception if @RunWith(Cucumber.class) classes have methods.

[aslakhellesoy]

People are bound to misuse classes annotated with @RunWith(Cucumber.class) by putting stepdefs in them. This is bad because it couples stepdefs to features, and confuses people. In fact, two instances of the class will be created. -One by JUnit and one by the DI container.

@RunWith(Cucumber.class) annotated classes are meant to be empty and should serve a single purpose: kick of cucumber to run a feature.

Forcing users to put stepdefs elsewhere will hopefully help them understand the difference.

[pqueixalos]

I have an issue using coverage utilities with Cucumber since this fix (ie JaCoCo).
Those tools instrument the Test class so I think the call to cumcumber.junit.Cucumber#assertNoDeclaredMethods(clazz) should be optional.

[eeichinger]

I understand from a technical perspective. From a conceptual perspective though I'd rather prohibit reusing stepdefs among multiple features

[aslakhellesoy]

@eeichinger why?

[eeichinger]

if I understand your co-author Matt correctly from your cucumber book as well as his talk "BDD As It's Meant To Be Done" - and I fully agree with that - then sharing stepdefs is a bad idea as it inevitably leads to scripting instead of specifying. Rather implement any logic in your underlying testing model.
In the past I found myself wishing for having all stepdefs for 1 feature as 1 isolated unit for exactly this reason

[aslakhellesoy]

This sounds like https://github.com/cucumber/cucumber/wiki/Feature-Coupled-Steps-(Antipattern) - and I don't think we're intentionally advocating this anywhere in the book. Do you remember what chapter(s) gave you this impression?

I have to see @mattwynne's presentation again to see where he is advicating this (sounds like a misunderstanding).

[mattwynne]

@eeichinger I do advocate writing high-level steps, but I wouldn't agree that they should be coupled to particular features. A key benefit of using Cucumber is that it promotes the use of a ubiquitous language for describing the behaviour of your system. If your step definitions are visible globally, then you have to use language that makes sense across the whole project.

What I hope I explained both in that talk and in the book, is that the important thing is to push all the scriptey behaviour down into code that supports your step definitions, and keep the step definitions very thin. Then you get the best of both worlds: high level, readable features and maintainable step definitions.

[eeichinger]

First of all thanks for taking the time to reply!

Reusing stepdefs across features to promote UL is an Interesting point. From my experience it unfortunately never worked out. The ability to technically reuse stepdefs on gherkin-level always ultimately led to create more and more fine-grained steps over time, ending up in exactly the scripts we are all trying to avoid.
Also (forgive me, the example has its limits, but I hope I get across the point) "I provide my valid PIN code" might have 1 defined meaning on the domain language level, but its stepdef might require different implementations due to different feature contexts, e.g. entering the PIN code via webbrowser or sending it via SMS.

Probaly we're doing it wrong, but I experienced this problem quite often in the past. That's why I'd rather have a dedicated set of stepdefs for a particular feature (or a related group of features) rather than having the same stepdefs globally visible to all features

[remast]

There is a issue #258 about running Cucumber with JaCoCo Code Coverage. Does that help you?

[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.