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
