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" <mauro.tal...@aquilonia.org> ezt írta: > 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 >> >> >>
