Re: [jbehave-dev] embeddable steps
Gherkin has no concept of GivenStories so I'm not sure what you are comparing it too. Gherkin's Background is entirely different and is supported in JBehave by Lifecycle (since 3.9). On 9 Jul 2013, at 17:10, Czigola Gábor wrote: > Wow, great news. Not certain yet how to configure GivenSories' PathCalculator > and StoryLoader to work with gdocs, but I'll figure it out and report on > findings. > > Many thanks for the feedback. I hope to contribute to the codebase this > regard... > > If you allow a comment: compared to the clean and natural gherkin wording, > GivenStories syntax (scenario id, parameter passing) appears a bit clumsy and > techy. > > 2013.07.09. 16:18, "Mauro Talevi" ezt írta: >> This is already planned in JBEHAVE-923. >> >> >> On 9 Jul 2013, at 14:01, Czigola Gábor 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" 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? W
Re: [jbehave-dev] embeddable steps
Wow, great news. Not certain yet how to configure GivenSories' PathCalculator and StoryLoader to work with gdocs, but I'll figure it out and report on findings. Many thanks for the feedback. I hope to contribute to the codebase this regard... If you allow a comment: compared to the clean and natural gherkin wording, GivenStories syntax (scenario id, parameter passing) appears a bit clumsy and techy. 2013.07.09. 16:18, "Mauro Talevi" ezt írta: > This is already planned in JBEHAVE-923. > > > On 9 Jul 2013, at 14:01, Czigola Gábor 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" 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 >> >> >>
Re: [jbehave-dev] embeddable steps
This is already planned in JBEHAVE-923. On 9 Jul 2013, at 14:01, Czigola Gábor 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" 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
Re: [jbehave-dev] embeddable steps
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" 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 > > >
Re: [jbehave-dev] embeddable steps
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
[jbehave-dev] embeddable steps
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
