Cucumber "Background" vent (and request for advice)

[Abe Heward]

I can't imagine I'm the only person to run into this issue, so maybe someone has an easy answer for me.  I'm posting this rant/venting here because I'd like the perspective of Cucumber users who also use Watir/Watir-webdriver, like me.

Cucumber has "Before" and "Background", but these happen either before ALL scenarios or before EVERY scenario.

Why this annoying limitation?

I want an option to have something happen before the first scenario in a feature.

Use case:

I want to test the features on a web page, but I first need to navigate to that web page.  I don't need to navigate to that web page EVERY TIME for every scenario tested in the feature.  And I ALSO don't need to navigate to that page before every other feature. So, "Background" becomes utterly worthless to me.

It seems like the only answer is tagging things, but aside from being ugly, it's not as useful as it should be--for example, say I want to declare some variables for a feature that will be used in multiple scenarios.  Suddenly I have to put multiple "Before" clauses in my step definitions, with various tags associated with each of them.

Ugly. Annoying.

Now, admittedly, I'm a total Cucumber n00b, so there's every possibility that I've missed something important, here.

Please, someone tell me that I'm just suffering from ignorance and need to be schooled.

Please.

Abe

[Oscar Rieken]

quick example but you may get the idea you can have a step that accepts a url and hands it to your browser and you can have a hook that always goes to a certain place by default

hooks.rb
Before do
@browser = Watir::Browser.new :chrome
end

Before("@main_site") do
@browser.goto "www.somesite.com"
end

some.feature

Background: Given I am an active user

@main_site
Scenario: go log into some site
When I try to log in with a valid password
Then I should see my dashboard

@main_site
Scenario: go log into some site
When I try to log in with an invalid password
Then I should not see my dashboard


some_other.feature

Given I am on "someother.com"
When I try to look do something
Then I should be able to



or you can do something like pulling urls from a fixture
@browser.goto :main_site

@browser.goto :other_site


and have different steps depending on what page you need to go to

Abe

--
Before posting, please read http://watir.com/support. In short: search before you ask, be nice.
 
watir-...@googlegroups.com
http://groups.google.com/group/watir-general
watir-genera...@googlegroups.com

[Abe Heward]

Thanks for the post.

You're using tags, which, again, is my primary complaint.

But I guess that's the direction I'm going to have to go in, if we're going to use Cucumber.

watir-general+unsubscribe@googlegroups.com

[Abe Heward]

Not to mention your "given I'm an active user" is now going to happen before EVERY scenario.  That's ugly.  Every scenario isn't necessarily going to need that information.

This is a really surprising limitation in cucumber functionality, to my mind.

Abe

[Oscar Rieken]

tags or additional steps pointing you to the site you want to go to
all of our feature files are kept in the same directory for about 6 different applications including mobile

you could push that sort of thing down into the framework you have around your site and then it would just be a matter of building it that way
if you are having problems figuring out how you want to build the framework itself i suggest taking a look at taza https://github.com/hammernight/taza or page-object https://github.com/cheezy/page-object/

watir-genera...@googlegroups.com

[Oscar Rieken]

not every scenario only every scenario in that feature file
so if that feature was called things_only_for_active_users.feature it would not run for any other feature

watir-genera...@googlegroups.com

[Abe Heward]

No problems with the framework. I'm already using Page-Object and have even gemified the API: https://rubygems.org/gems/sakai-oae-test-api 

Thanks again for the help. 

watir-general+unsubscribe@googlegroups.com

[Abe Heward]

" not every scenario only every scenario in that feature file"

... You see, but this is exactly what I don't want!

Feature: Cucumber with an option to run "givens" only on the first scenario of a feature

As a Cucumber User

I want to have a Background option that runs only for the first scenario without requiring a tag on that scenario

So that I don't have to hide stuff in Hooks or "Before" clauses that the business side can't see

And the business side doesn't have to look at ugly code-like crap like "@starting_test" in their feature files 

And I can have site navigation steps that only occur at the beginning of testing a web site feature 

 

Scenario: Running multiple tests on a web page that requires user login, without logging in before every scenario

Given: I have a "Background" clause in my Feature definition

 And: I want to log in ONCE to the web site I'm testing with Cucumber

When: I put the log-in step into the Background of the Feature definition 

Then: I should see my scenarios in the feature only log in with the first scenario

Oops. This test fails. :-( 

 

 

watir-general+unsubscribe@googlegroups.com

watir-general+unsubscribe@googlegroups.com

[Chuck van der Linden]

On Friday, May 18, 2012 12:50:02 PM UTC-7, Abe Heward wrote:

" not every scenario only every scenario in that feature file"

... You see, but this is exactly what I don't want!

but you DO want it. (I think you just don't understand why) 

Here's the thing, each scenario should be able to stand on its own.  You want the tests to be atomic, each one should set the system into the state it needs, execute the actions needed for the script, and return the system to a known state (clean up after itself).  You want the tests to be able to be run in any order, or in any subset.  You want them to be able to run in parallel in a grid so you can run a large number of tests rapidly.   You also want to be able to have stakeholders review scenarios in relative isolation especially if you are just adding a few new scenarios to a feature.  When considering scenarios you don't want your stakeholders to have to track the state of the system from scenario to scenario, you should be able to look at each one in isolation (along with any background) and have it make sense and 'work' 

Making the assumption that you can just navigate to the needed page once for a set of scenarios leaves you open to a bunch of potential problems down the line.  You might think it's ugly or redundant, but you are far better off for each test to be able to be atomic and stand entirely on it's own. This prevents problems such as 'coupled tests' where a failure in an earlier test that leaves the system in an unknown state (such as on a different page or an error message) and that could cause all following tests in that feature file to fail. 

In the long run having atomic tests has a lot of benefits, not the least of which would be that if you have a single failing scenario, you could tag it with a bug number making it easy for a developer or tester to run just that one test, then remove the tag once it is fixed and validated.

Another small example would be when developing a new scenario in a feature file.  I tag such scenarios @WIP  (for work in progress) and that makes it very easy for me to run just that one scenario, see what steps are passing, what steps I might need to create, etc.  

To extend that example, a similar thing also happens when you decide which scenarios should be run when.  For example you might have several scenarios in a feature file, and a small subset of them may be tagged using something like @Web_Smoke and you have those run against a single browser by the CI system for each build after the unit tests pass.  At the same time others tagged with something like @Web_Overnight and they represent a more extensive set of tests that you have the CI system run every night, against multiple browsers.

I'd strongly recommend buying and reading 'The Cucumber Book'  it discusses a lot of the things that can make for bad tests that are brittle, or have dependencies between tests.