Hi Fellows, There is a dilemma I stumbled upon multiple times while implementing BDD testing:
Scenario: login. Given I navigato to the landing page Given I enter USER into #username Given I enter PASS into #password When I click #login Then I have #profileDiv So far so good. This works excellent. However, many if not most of your scenarios will start by logging in first. You are confronted with a choice: either copy paste these lines everywhere (DRY?!), or implement login as a single step. Scenario: logout. Given I'm logged in as "USER", "PASS" When I click on #logout Then I have #loginDiv I've experience this latter as a definitive antipattern: it fights the very purpose of JBehave, the ability to define the accepted behaviour as atomic steps in the gherkin language. Testers tend to write smelly code, pushing down this sort of logic into the implementation results in bad maintainability and bad test quality. You end up with different implementations for the same (sub)scenarios, and performing something non-atomic in one step can shadow bugs. What I could think of as a solution and enhancement to JBehave are embeddable step definitions: Definition: authenticate. Given I navigato to the landing page Given I enter USER into #username Given I enter PASS into #password When I click #login Scenario: login works. Subsumed authenticate. Then I have #profileDiv Scenario: logout works. Subsumed authenticate. When I click on #logout Then I have #loginDiv IMHO this would be a relatively cheap and backwards compatible change in JBehave but a significant gain. It would simplify and improve what is possible in stories. It would make the definitions more re-usable, extendible and maintainable. Additional considerations: - Proper naming and conventions for "Definition" (same as scenario, only not executed only when subsumed elsewhere) and "Subsumed". - Be able to parametrize subsumtions, or pass example parameters from the scenario to the subsumed definition. Subsumed authenticate. | USER | PASS | | xyxy | xyxy | - Take subsumtions into account when generating reports (just execute included steps as if they were part of the original scenario, but indent the results) - This must not bring Turing-completeness to gherkin. This is like a pre-processor substitution, not partial recursion. Infinite includes can be simply avoided by maintaining a set of subsumed definitions along the chain, throwing an error upon a duplicate. What do you think? Has this been discussed before? What problems, side effects do you see? Do you think this could be an useful improvement? Have been looking into the source, it takes time but I could implement it with ease. (Requires change in the parser, embedder, reporter, tests, documentation and examples.) Regards, Gábor Czigola
