This is already planned in JBEHAVE-923.
On 9 Jul 2013, at 14:01, Czigola Gábor <czig...@gmail.com> wrote: > Looks like a very promising direction. I see some limitations though: > > - Embedding occurs on a story level wherbey I've seen the need for embedding > only particular scenarios in part or in full. (E.g. a login.story file would > include various login scenarios wherby you are looking forward to include > only a single scenario that logs you in and does nothing more.) > > - It is heavy coupling to introduce path/file names in the story files. What > if StoryText is not loaded from the classpath, not boundled with the test > framework but provided by google docs or other means? Where are these paths > referring to? > > Would it make sense to introduce GivenScenario and not to use a path to > reference it? (Reference by name, tag instead.) > > Thx, > Gabor > > 2013.07.09. 12:18, "Cristiano Gavião" <cvgav...@gmail.com> ezt írta: >> maybe I didn't understand your need properly. >> >> but why not to use parametrized given-stories [1] for login ? >> >> regards, >> >> Cristiano >> >> >> [1]-http://jbehave.org/reference/latest/given-stories.html >> >> On 09/07/13 07:03, Gabor Czigola wrote: >>> 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
