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