Re: [Gherkin] How to test for same feature with multiple backgrounds

[Augusto Evangelisti]

On Friday, 9 November 2012 13:39:49 UTC, Tim Diggins wrote:

I can imagine doing this by writing a "Background Outline" with a table of specifics (parallel to how Scenario outlines work). Alternatively I could abstract a list of Scenarios into a separate file and 'include' the scenarios into two different features (each with their own background)

Tim, I understand what you want to do and the rationale behind it but I would not do it and would rather go with the duplication.

A Background Outline would resolve your technical issue but would make the flow of the test almost unreadable.

Feature files, in my humble opinion, are not pieces of code, they tell a tale, don't forget that also people read them, not only the Gherkin parser.

Gus

[Roberto Lo Giacco]

Hi, this in my opinion is a quite common scenario and I was thinking that once again tags can help us avoid the duplication, but I'm not sure.
What about annotating those features/scenarios with @runAsGroup1 and @runAsGroup2 and execute the tests twice providing different credentials as system properties or so? Documentation wise you still retain the fact that a scenario has to be valid for both groups, execution results wise you can use an After hook to embed the user that has been used for the test as a result text and eventually merge the results for a unified report.
If you guys think this can be a viable solution I can prepare a more detailed explanation in a blog post.
The drawback of this solution is you will need to run your tests multiple times (once per each group/role) and you'll need to merge the results if you want a single full report, but documentation wise this should be fine.

[George Dinwiddie]

Tim,

On 11/9/12 6:39 AM, Tim Diggins wrote:
> I've got a feature which was written for one user group (and explicitly
> excluded from another) and now times (and requirements) have changed and
> we need to make the same feature available to another user group. So
> ideally I'd like to run the same set of Scenarios with two different
> backgrounds. I can imagine doing this by writing a "Background Outline"

> with a table of specifics (parallel to how Scenario outlines work).
> Alternatively I could abstract a list of Scenarios into a separate file
> and 'include' the scenarios into two different features (each with their

> own background).
>
> Is there any way of supporting this in Gherkin? Or failing that where
> would I start (and at least not-totally-inadvisable) to extend Gherkin
> to do either of these?
>
> I've written this up in more detail
> in http://stackoverflow.com/questions/13141894/how-to-test-for-same-feature-with-multiple-backgrounds-in-cucumber.
> Feel free to reply in either place.

The stackoverflow posting shows the syntax you imagine, but doesn't
really show the need for it.

I can't really imagine the need for running every scenario with every
user role. That sort of exhaustive testing smells mechanical to me, and
suggests not thinking deeply about the need. For the scenarios that
don't change based on role, why is testing each role necessary? Is it
highly likely that a mistake will be made such that one role will work
and another will not? And, if so, is this something that is being worked
out in conversation with the representative from the business? Or
perhaps you'd do better using a code-based tool to check all permutations.

I can envision some scenarios where the role is varied in the Given and
the expectation is sometimes the same and sometimes different in the
Then part of a scenario outline. That seems reasonable for checking the
role-based behavior.

I guess I'd have to see the scenarios to understand your need.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Rex Hoffman]

Sorry for the late reply.   Been off the list for a while.

On Saturday, November 10, 2012 2:50:59 PM UTC-8, George Dinwiddie wrote:

Tim,

On 11/9/12 6:39 AM, Tim Diggins wrote:
> I've got a feature which was written for one user group (and explicitly
> excluded from another) and now times (and requirements) have changed and
> we need to make the same feature available to another user group. So
> ideally I'd like to run the same set of Scenarios with two different
> backgrounds. I can imagine doing this by writing a "Background Outline"
> with a table of specifics (parallel to how Scenario outlines work).
> Alternatively I could abstract a list of Scenarios into a separate file
> and 'include' the scenarios into two different features (each with their
> own background).
>
> Is there any way of supporting this in Gherkin? Or failing that where
> would I start (and at least not-totally-inadvisable) to extend Gherkin
> to do either of these?
>
> I've written this up in more detail
> in http://stackoverflow.com/questions/13141894/how-to-test-for-same-feature-with-multiple-backgrounds-in-cucumber.
> Feel free to reply in either place.

The stackoverflow posting shows the syntax you imagine, but doesn't
really show the need for it.

I use @DESKTOP and @MOBILE tags to mark features as supported by the mobile and desktop version of our application.

They are highly overlapping sets of features that enable the same capability, and as a result share the same language.

I'm hoping to see this drive higher levels of collaboration in my organization.

I use spring to compose the context I need.  I run cucumber twice to achieve running the @MOBILE and @DESKTOP tests in the slightly different contexts.

If the cucumber-jvm's reporting wasn't so temporally bound to it's execution and a bit more flexible, I would probably attempt to do this as a single run.  I'd want to solve multithreading before then as well.

I imagine this being fairly common (I would guess that  a quarter to a half the organizations running cucumber trying to reuse the language across multiple implementations of there UIs)

The logic applied to tags is a little lacking.   Being able to express something like

{@DESKTOP @SMOKE}   {@MOBILE}

Scenario: ....

where each group expressed a run, and the information contained in the tag could then be used a before method to start a scope within the spring context.

The expected behavior would be to run the outline twice by default.   If I only ran smoke tests it would run once on the desktop configured context. 

Even what I'm currently doing with tags this is an abuse of tags as I believe they were envisioned by the authors.  However the I don't see any other way with going crazy with scenario outlines to support feature/language reuse across different UIs to the same applicaiton.

Rex

[Matt Wynne]

On 19 Dec 2012, at 18:43, Rex Hoffman wrote:

The logic applied to tags is a little lacking.   Being able to express something like

{@DESKTOP @SMOKE}   {@MOBILE}

Scenario: ....

where each group expressed a run, and the information contained in the tag could then be used a before method to start a scope within the spring context.

Wouldn't that amount to duplication though, because you'd have to put those brackets on every scenario where you used that tag pattern?

I've been thinking it would be nice to be able to document the tags somewhere - explain what each one means. Maybe we should have a cucumber.tags file where you can put both these bits of information?

cheers,

Matt

--
Freelance programmer & coach
Author, http://pragprog.com/book/hwcuc/the-cucumber-book
Teacher, http://bddkickstart.com

Founder, http://www.relishapp.com/
Twitter, https://twitter.com/mattwynne

[Rex Hoffman]

On Friday, December 21, 2012 12:47:41 PM UTC-8, Matt Wynne wrote:

On 19 Dec 2012, at 18:43, Rex Hoffman wrote:

The logic applied to tags is a little lacking.   Being able to express something like

{@DESKTOP @SMOKE}   {@MOBILE}

Scenario: ....

where each group expressed a run, and the information contained in the tag could then be used a before method to start a scope within the spring context.

Wouldn't that amount to duplication though, because you'd have to put those brackets on every scenario where you used that tag pattern?

Again the late reply on my part, but here goes...

It would be a bit of duplication, but far less than the duplication of feature files (one for each target environment?)  Though this could be used at the top of a feature as well.

If you do something like this.

SomeCapabilityCommonToAllApps.feature  {@DESKTOP @MOBILE}

SomeCapabilityDesktop.feature {@DESKTOP}

SomeCapabilityMobile.feature {@MOBILE}

Or if you don't mind the duplication by putting it on the scenario level you could have one file for cohesion (all the information around that capability described in one place.) 

 

I've been thinking it would be nice to be able to document the tags somewhere - explain what each one means. Maybe we should have a cucumber.tags file where you can put both these bits of information?

Having a description of intended use would be beneficial, but right now we're not exploiting the capabilities of the jvm (multithreading, stateless object reuse, and some very important state management of Dependency Injection containers) and that would be a much higher priority as that affects adoption rates by java based organizations, and within those organizations.

Fast turn around is always a win. 

 

The documentation is very easy for an organization to express either in print out in a build or else where.   Lack of communication about how to run cucumber-jvm is a barrier to adoption, but I dont see us getting around that soon in jvm land with the cucumber-junit and Main runners, not to mention the nascent ide plugins.  Perhaps cleaning that up would lead to a more stable, capable api which could allow for those jvm capabilities to be exploited, though? hmm.

I would not mind doing some of this work but I wouldn't want is to be rejected out of hand, or languishing in pull request for months, wasting all of our time.

Happy Festivus,

Rex

[Matt Wynne]

On 31 Dec 2012, at 19:26, Rex Hoffman wrote:

On Friday, December 21, 2012 12:47:41 PM UTC-8, Matt Wynne wrote:

On 19 Dec 2012, at 18:43, Rex Hoffman wrote:

The logic applied to tags is a little lacking.   Being able to express something like

{@DESKTOP @SMOKE}   {@MOBILE}

Scenario: ....

where each group expressed a run, and the information contained in the tag could then be used a before method to start a scope within the spring context.

Wouldn't that amount to duplication though, because you'd have to put those brackets on every scenario where you used that tag pattern?

Again the late reply on my part, but here goes...

It would be a bit of duplication, but far less than the duplication of feature files (one for each target environment?)  Though this could be used at the top of a feature as well.

If you do something like this.

SomeCapabilityCommonToAllApps.feature  {@DESKTOP @MOBILE}

SomeCapabilityDesktop.feature {@DESKTOP}

SomeCapabilityMobile.feature {@MOBILE}

Or if you don't mind the duplication by putting it on the scenario level you could have one file for cohesion (all the information around that capability described in one place.) 

I've worked with a team that builds an app that runs on multiple different TVs and set-top boxes. They use one set of features, but not all of the devices support all of the scenarios. They way they approach this is to tag scenarios that are _not_ supported on a particular platform. Using that model you'd have @not-desktop @not-mobile etc on some of the scenarios. This works well for them,

Would that work for you?

I've been thinking it would be nice to be able to document the tags somewhere - explain what each one means. Maybe we should have a cucumber.tags file where you can put both these bits of information?

Having a description of intended use would be beneficial, but right now we're not exploiting the capabilities of the jvm (multithreading, stateless object reuse, and some very important state management of Dependency Injection containers) and that would be a much higher priority as that affects adoption rates by java based organizations, and within those organizations.

Fast turn around is always a win. 

 

The documentation is very easy for an organization to express either in print out in a build or else where.   Lack of communication about how to run cucumber-jvm is a barrier to adoption, but I dont see us getting around that soon in jvm land with the cucumber-junit and Main runners, not to mention the nascent ide plugins.  Perhaps cleaning that up would lead to a more stable, capable api which could allow for those jvm capabilities to be exploited, though? hmm.

I would not mind doing some of this work but I wouldn't want is to be rejected out of hand, or languishing in pull request for months, wasting all of our time.

I can't really comment on the JVM project, but I don't think pull requests with documentation in will languish. Other issues should just be dealt with in small pieces. I think a nice way to start the conversation is with a failing feature that describes what you'd like the tool to be able to do.

Happy Festivus,

Rex

cheers,

Matt

--
Freelance programmer & coach
Author, http://pragprog.com/book/hwcuc/the-cucumber-book
Teacher, http://bddkickstart.com

Founder, http://www.relishapp.com/
Twitter, https://twitter.com/mattwynne

--
-- Rules --
 
1) Please prefix the subject with [Ruby], [JVM] or [JS].
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
3) If you have a question, don't reply to an existing message. Start a new topic instead.
 
You received this message because you are subscribed to the Google Groups Cukes group. To post to this group, send email to cu...@googlegroups.com. To unsubscribe from this group, send email to cukes+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/cukes?hl=en
 
 

[Rex Hoffman]

On Wednesday, January 2, 2013 8:20:57 AM UTC-8, Matt Wynne wrote:

On 31 Dec 2012, at 19:26, Rex Hoffman wrote:

On Friday, December 21, 2012 12:47:41 PM UTC-8, Matt Wynne wrote:

On 19 Dec 2012, at 18:43, Rex Hoffman wrote:

The logic applied to tags is a little lacking.   Being able to express something like

{@DESKTOP @SMOKE}   {@MOBILE}

Scenario: ....

where each group expressed a run, and the information contained in the tag could then be used a before method to start a scope within the spring context.

Wouldn't that amount to duplication though, because you'd have to put those brackets on every scenario where you used that tag pattern?

Again the late reply on my part, but here goes...

It would be a bit of duplication, but far less than the duplication of feature files (one for each target environment?)  Though this could be used at the top of a feature as well.

If you do something like this.

SomeCapabilityCommonToAllApps.feature  {@DESKTOP @MOBILE}

SomeCapabilityDesktop.feature {@DESKTOP}

SomeCapabilityMobile.feature {@MOBILE}

Or if you don't mind the duplication by putting it on the scenario level you could have one file for cohesion (all the information around that capability described in one place.) 

I've worked with a team that builds an app that runs on multiple different TVs and set-top boxes. They use one set of features, but not all of the devices support all of the scenarios. They way they approach this is to tag scenarios that are _not_ supported on a particular platform. Using that model you'd have @not-desktop @not-mobile etc on some of the scenarios. This works well for them,

Would that work for you?

Sure, it's the logical equivalent of marking the ones that are supported, which is what we are currently doing.

I've been thinking it would be nice to be able to document the tags somewhere - explain what each one means. Maybe we should have a cucumber.tags file where you can put both these bits of information?

Having a description of intended use would be beneficial, but right now we're not exploiting the capabilities of the jvm (multithreading, stateless object reuse, and some very important state management of Dependency Injection containers) and that would be a much higher priority as that affects adoption rates by java based organizations, and within those organizations.

Fast turn around is always a win. 

 

The documentation is very easy for an organization to express either in print out in a build or else where.   Lack of communication about how to run cucumber-jvm is a barrier to adoption, but I dont see us getting around that soon in jvm land with the cucumber-junit and Main runners, not to mention the nascent ide plugins.  Perhaps cleaning that up would lead to a more stable, capable api which could allow for those jvm capabilities to be exploited, though? hmm.

I would not mind doing some of this work but I wouldn't want is to be rejected out of hand, or languishing in pull request for months, wasting all of our time.

I can't really comment on the JVM project, but I don't think pull requests with documentation in will languish. Other issues should just be dealt with in small pieces. I think a nice way to start the conversation is with a failing feature that describes what you'd like the tool to be able to do.

unfortunately json report bug/fix in gherkin shows others, we've been using my github branch for several months now....