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. > > 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. :-(* > > > > > > > On Friday, May 18, 2012 12:29:04 PM UTC-7, Oscar.Rieken wrote: >> >> 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 >> >> On Fri, May 18, 2012 at 3:25 PM, Abe Heward <[email protected]> wrote: >> >>> 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 >>> >>> >>> On Friday, May 18, 2012 12:22:17 PM UTC-7, Abe Heward wrote: >>>> >>>> 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. >>>> >>>> On Friday, May 18, 2012 12:11:03 PM UTC-7, Oscar.Rieken wrote: >>>>> >>>>> 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 >>>>> >>>>> On Fri, May 18, 2012 at 2:31 PM, Abe Heward <[email protected]>wrote: >>>>> >>>>>> 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 >>>>>> >>>>>> -- >>>>>> Before posting, please read http://watir.com/support. In short: >>>>>> search before you ask, be nice. >>>>>> >>>>>> [email protected] >>>>>> http://groups.google.com/**group/watir-general<http://groups.google.com/group/watir-general> >>>>>> watir-general+unsubscribe@**googlegroups.com<watir-general%[email protected]> >>>>>> >>>>> >>>>> -- >>> Before posting, please read http://watir.com/support. In short: search >>> before you ask, be nice. >>> >>> [email protected] >>> http://groups.google.com/group/watir-general >>> [email protected] >>> >> >> > On Friday, May 18, 2012 12:29:04 PM UTC-7, Oscar.Rieken wrote: >> >> 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 >> >> On Fri, May 18, 2012 at 3:25 PM, Abe Heward <[email protected]> wrote: >> >>> 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 >>> >>> >>> On Friday, May 18, 2012 12:22:17 PM UTC-7, Abe Heward wrote: >>>> >>>> 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. >>>> >>>> On Friday, May 18, 2012 12:11:03 PM UTC-7, Oscar.Rieken wrote: >>>>> >>>>> 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 >>>>> >>>>> On Fri, May 18, 2012 at 2:31 PM, Abe Heward <[email protected]>wrote: >>>>> >>>>>> 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 >>>>>> >>>>>> -- >>>>>> Before posting, please read http://watir.com/support. In short: >>>>>> search before you ask, be nice. >>>>>> >>>>>> [email protected] >>>>>> http://groups.google.com/**group/watir-general<http://groups.google.com/group/watir-general> >>>>>> watir-general+unsubscribe@**googlegroups.com<watir-general%[email protected]> >>>>>> >>>>> >>>>> -- >>> Before posting, please read http://watir.com/support. In short: search >>> before you ask, be nice. >>> >>> [email protected] >>> http://groups.google.com/group/watir-general >>> [email protected] >>> >> >> -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected]
