Forum: RSpec Before and After blocks for individual feature files?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Doug L. (Guest)
on 2009-04-28 16:52
(Received via mailing list)
Hi -- is it possible to set before and after blocks for individual
feature
files?
I've tried putting them in step files, but they just get called before
everything, like they'd been declared in env.rb, which is consistent
with
how I thought cucumber worked, but I thought I'd best try it anyway.
Anyway, I have some features that require a specific state be set up
before
they run -- is this possible to do, and how would I go about doing it?
Thanks for any & all help,
   Doug.
Julian L. (Guest)
on 2009-04-28 17:38
(Received via mailing list)
Perhaps use background?

Julian.
Doug L. (Guest)
on 2009-04-28 18:12
(Received via mailing list)
Brilliant, cheers!
   Doug.

2009/4/28 Julian L. <removed_email_address@domain.invalid>
Aslak H. (Guest)
on 2009-04-28 18:13
(Received via mailing list)
> Hi -- is it possible to set before and after blocks for individual feature
> files?


Yes. Use tagged hooks:
http://wiki.github.com/aslakhellesoy/cucumber/hooks

Aslak
Arco (Guest)
on 2009-04-28 19:41
(Received via mailing list)
I also would like a hook that executes a block once before running a
feature file.

In my testing i found that:
- Background: executes before each scenario
- Before executes before each scenario
- Before('@tag') executes before each scenario

Is there a way to execute a block once before each feature, but not
before each scenario?
Aslak H. (Guest)
on 2009-04-28 20:03
(Received via mailing list)
On Tue, Apr 28, 2009 at 5:32 PM, Arco <removed_email_address@domain.invalid> 
wrote:

>
No :-)
Arco (Guest)
on 2009-04-28 20:36
(Received via mailing list)
OK - I found a workaround.  I simply tag the first scenario with
'@first', then
do Before('@first') and i get what I want - executing a block once for
the feature file.

Except for one problem:  most of my scenarios are done as scenario
outlines, which
are run multiple times - once for each row of my Example table.

A workaround to that problem might be to put a 'dummy' scenario that
is run before the other scenarios in my feature file...

  @first
  Scenario: Call a before block before running other scenarios...

But this puts junk in my feature files.  Is there a better, cleaner
way??
Aslak H. (Guest)
on 2009-04-28 20:45
(Received via mailing list)
On Tue, Apr 28, 2009 at 6:15 PM, Arco <removed_email_address@domain.invalid> 
wrote:

> is run before the other scenarios in my feature file...
>
>  @first
>  Scenario: Call a before block before running other scenarios...
>
> But this puts junk in my feature files.  Is there a better, cleaner
> way??
>

a) Why do you need one thing to happen before a feature?
b) Why can't you do it before each scenario?

Aslak
Arco (Guest)
on 2009-04-28 22:14
(Received via mailing list)
I'd like to do this:

  Feature: user signup
  Before:
    Given I have a cleaned up database
  Scenario Outline: Sign Up
    Given I am on the signup page
    When I sign up using <userid>
    Then I should see <message>
   Examples:
    |userid     |message           |
    |userX      |successful signup |
    |userX      |duplicate userid  |

"I have a cleaned up database" runs before every example, making the
second example ('duplicate userid') fail.
Ben M. (Guest)
on 2009-04-28 22:32
(Received via mailing list)
Arco wrote:
>     |userid     |message           |
>     |userX      |successful signup |
>     |userX      |duplicate userid  |
>
> "I have a cleaned up database" runs before every example, making the
> second example ('duplicate userid') fail.
>


You could use Background and it would work just like you want it to:

  Feature: user signup
  Background:
    Given I have a cleaned up database
  Scenario Outline: Sign Up
    Given I am on the signup page
    When I sign up using <userid>
    Then I should see <message>
   Examples:
    |userid     |message           |
    |userX      |successful signup |
    |userX      |duplicate userid  |


However, I would not encourage this.  You should try to avoid using
technical words, such as database, in your features.  If anything you
could say "Given no users exist" or something like that.  Keeping your
database clean is something you generally want for every scenario
though.  So I would suggest putting the code in your "Given I have a
cleaned up database" code into a Before block.  The wiki has a page on
using the Before hook:
http://wiki.github.com/aslakhellesoy/cucumber/hooks

Basically, in your env.rb file you will add something like:

Before do
  Database.clean! # or however you clean your DB
end



HTH,
Ben
Arco (Guest)
on 2009-04-28 23:00
(Received via mailing list)
Thanks for your reply Ben.  +1 on your wording recommendation - I
understand and agree 100%

However - for me - the Background block executes before each example
in the table.  Therefore, the database is cleared twice, and the
second example ('duplicate userid') fails.

(Cucumber 0.3.1 / ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-cygwin])

Here are some snippets from a little workaround that i've employed...
in env.rb:
  State = {'feature_file'=>'initialize'}
in my_steps.rb:
  unless State['feature_file'] ==
@__cucumber_current_step.file_colon_line.split(':').first
    puts "CLEANUP CODE HERE - RUN ONCE PER FEATURE FILE  --------"
  end
  State['feature_file'] =
@__cucumber_current_step.file_colon_line.split(':').first

I'm sure there must be a better way!  I am still learning cucumber so
any advice is welcome!
;-)
Kero van Gelder (Guest)
on 2009-04-29 03:12
(Received via mailing list)
>     |userid     |message           |
>     |userX      |successful signup |
>     |userX      |duplicate userid  |

Feature: user signup

  Scenario: succesful signup
    When I sign up using Kero
    Then I should see welcome Kero

  Scenario: failed signup of existing user
    Given there is a user Kero
    When I sign up using Kero
    Then I should see trying to impersonate someone else

NB: yes, clean the database before every scenario

Bye,
Kero.

___
How can I change the world if I can't even change myself?
  -- Faithless, Salva Mea
Julian L. (Guest)
on 2009-04-29 06:03
(Received via mailing list)
Hey Ben,

It'd be kinda cool if there was a sort of before and after for a
feature rather than each scenario. Is there?

(Rails context) We often need this. It'd be really helpful for things
like when we want to test about 15 things on a particular web page,
and they don't require fresh data. We end up with a login and setup
type background which gets run every time rather than simply once.

I guess we could refactor it into a set of examples perhaps... would
that work? It just strikes me as quite complicated. It'd be awesome if
we had sub-scenarios (and they could be specified to levels) ;-)
Perhaps I'm just being too complicated.

I loved your rubyconf talk presentation, BTW. We kinda took exception
to the bit where you said "Selenium just works", though. There are a
number of things where the connection between selenium and webrat is a
little tenuous and finicky about.

Also we seem to be having timing issues for AJAX requests with
Selenium. Webrat doesn't seem to want to wait until the AJAX request
as finished before doing the next thing. Any ideas here?

Julian.
Ben M. (Guest)
on 2009-04-29 07:31
(Received via mailing list)
Arco wrote:
> in env.rb:
> any advice is welcome!
> ;-)
>

While the above code is clever I would discourage its use.  IMO, it
looks like you are trying too hard to phrase your scenarios all within a
single scenario outline.  In this case I would not use tables but I
would have separate scenarios.  For example:

  Feature: user signup

  Scenario: success
    Given I am on the signup page

    When I enter valid registration information
    And I press "Register"

    Then I should see "You have signed up successfully!"

  Scenario: duplicate user with email # dunno, what really qualifies as
duplicate for you...
    Given I am on the signup page
    And a user with email "removed_email_address@domain.invalid" exists

    When I enter valid registration information
    And I fill in "Email" with "removed_email_address@domain.invalid"
    And I press "Register"

    Then I should see "A user has already signed up with 
removed_email_address@domain.invalid"



Does that make sense?  Basically, whenever you feel the need to embed a
conditional in your scenario it means you need a separate one.  You can
sometimes accomplish this by using scenario tables but that constrains
you to the same setup steps.  In your case you wanted additional context
for one of your scenarios in the table... this means that you probably
should have a whole new scenario like above.  Your current solution
obfuscates the additional context and therefore looses some of the
documentation value that Cucumber offers.

FWIW.

Oh, and please try not to top-post in the future - it makes threads hard
to follow. :)


-Ben
Ben M. (Guest)
on 2009-04-29 09:48
(Received via mailing list)
Julian L. wrote:
> Hey Ben,
>
> It'd be kinda cool if there was a sort of before and after for a
> feature rather than each scenario. Is there?

Nope.  There is no before(:all) equivalent in cucumber.  Just the Before
and After hooks, which are for scenarios.. and Backgrounds which are
just for scenarios on the given feature.
>
> (Rails context) We often need this. It'd be really helpful for things
> like when we want to test about 15 things on a particular web page,
> and they don't require fresh data. We end up with a login and setup
> type background which gets run every time rather than simply once.
 In the context of webrat a before(:all) would not help you a whole lot
since each scenario starts with a new session (so you have to login each
time, for example).  I understand the argument for complex data setup
though.  Having the same setup ran for each scenario can get costly.  I
haven't felt enough pain though to really justify adding something like
that.  Cleanup would be messy because we couldn't wrap it all in a
transaction AFAIK, so you would have to have an after(:all) like method
to clean up the feature.  For complex data that I rely on all the time I
tend to load it once with fixtures at boot up time within env.rb.  This
is usually for look-up data... but if you were really concerned about
record creation you could do something similar.  The question is if the
additional complexity of keeping all that global state in your head
worth the faster execution time.  For me it generally is not.
>
> I guess we could refactor it into a set of examples perhaps... would
> that work? It just strikes me as quite complicated. It'd be awesome if
> we had sub-scenarios (and they could be specified to levels) ;-)
> Perhaps I'm just being too complicated.

I would need more context to really answer your question.  However, can
I ask if your scenarios are written in a declarative or imperative
fashion[1]?  If they are written declaratively, or at least partly, then
you can specify a lot more behavior in a step without adding too much
noise to the scenario.  Another thing I should point out is that you
don't need to, and you shouldn't, test everything on the Cucumber
level.  For complex views, for example, it may be easier to do RSpec
examples (view specs) and just use Cucumber to test the basics.  In
general, I'm pretty wary about sub-scenarios and the like.  They could
be powerful, but they could very easily get complicated and turn
scenarios into a giant mess that only programmers could understand.
Feel free to share any ideas you have on the subject though and we'll
see what the tradeoffs are.  We love throwing new ideas around on the
list. :)
>
> I loved your rubyconf talk presentation, BTW. We kinda took exception
> to the bit where you said "Selenium just works", though. There are a
> number of things where the connection between selenium and webrat is a
> little tenuous and finicky about.

Thanks!  Yeah, the selenium adapter in webrat isn't nearly as mature as
the rails adapter. :(  I haven't had a lot of issues with it, but I try
to use it as least as possible and have only really used it on simple
things.  And to be honest, I haven't used it since January.  So, YMMV.
>
> Also we seem to be having timing issues for AJAX requests with
> Selenium. Webrat doesn't seem to want to wait until the AJAX request
> as finished before doing the next thing. Any ideas here?
I think I have seen people in #webrat on irc.freenode.net talk about
that and how they've had to add additional wait commands in. But, I
really don't know any details.  Sorry!  Your best bet is to ask in
#webrat, or on it's google group or lighthouse account.

-Ben

1.
http://www.benmabey.com/2008/05/19/imperative-vs-d...
Aslak H. (Guest)
on 2009-04-29 10:14
(Received via mailing list)
> Hey Ben,
>
> It'd be kinda cool if there was a sort of before and after for a feature
> rather than each scenario. Is there?
>

I think that would be particularly *un*cool actually, because people
would
start using it without understanding the implications.
Implications: Coupled, brittle scenarios.

Why do you think it would be useful?

Aslak
Arco (Guest)
on 2009-04-29 19:46
(Received via mailing list)
After some consideration, I agree with Aslak's and Ben's advice
against keeping context across an entire feature.

But I am still not convinced that it makes sense for create a new
context for each row of an example table.  As a newbie, I expected the
Before: block would be run once before the scenario, not once before
every row of the example table.  (so did Ben initially...)

Approach A -----------------------
Before:
  Given I have a clean database
Scenario Outline:  Signup Scenarios
  Given I start on the login page
  When I signup as <userid>
  Then I should see <message>
  Examples:
    | userid | message                 |
    | userA  | successful signup       |
    | userA  | error: duplicate userid |

Approach B ------------------------
Before:
  Given I have a clean database
Scenario:  Successful Signup
  Given I start on the login page
  When I signup as "userA"
  Then I should see "successful signup"
Scenario: Failure - Duplicate Userid
  Given I start on the login page
  When I signup as "userA"
  And I signup again as "userA"
  Then I should see "error: duplicate userid"

OK I will use Approach B, but ideally would prefer to use Approach A,
and personally find it easier to read and understand.

Thanks again for your feedback!  :)
Andrew V. (Guest)
on 2009-04-29 21:12
(Received via mailing list)
On Apr 29, 2009, at 8:45 AM, Arco wrote:

>  When I signup as <userid>
>  Then I should see <message>
>  Examples:
>    | userid | message                 |
>    | userA  | successful signup       |
>    | userA  | error: duplicate userid |



To me, "Examples" means separate, independent items.

If these are to be run under the same scenario in sequence, then the
table should be called something else, maybe "Sequence:" or "Steps:"

There might be other use cases for such a feature... I don't have any
to suggest at the moment, just brainstorming.

Andrew V.
Mark W. (Guest)
on 2009-04-29 22:06
(Received via mailing list)
On Wed, Apr 29, 2009 at 8:45 AM, Arco <removed_email_address@domain.invalid> 
wrote:


>    | userA  | error: duplicate userid |
>

If the desired behavior is sequential, then (to me), this is not a list
of
examples, but just a single example. So I'd find the separate scenarios
more
intention-revealing. If "Examples" were called "Steps," that would
describe
what you're going for in this particular case.

///ark
Julian L. (Guest)
on 2009-05-01 06:38
(Received via mailing list)
Hey ben,

Selenium is slow, and we have a lot of
Ajax, so I'm just looking at ways to speed it up. Tags will be my
first port of call and splitting out between automated and simulated.
It irks me we can't then simply run all our tests with one simple
cucumber command -we need two. It'd be nice if webrat could switch
between browser types per scenario or per feature. Sigh.

Blog: http://random8.zenunit.com/
Learn rails: http://sensei.zenunit.com/
Matt W. (Guest)
on 2009-05-01 15:42
(Received via mailing list)
On 1 May 2009, at 03:32, Julian L. wrote:

> Hey ben,
>
> Selenium is slow, and we have a lot of
> Ajax, so I'm just looking at ways to speed it up. Tags will be my
> first port of call and splitting out between automated and
> simulated. It irks me we can't then simply run all our tests with
> one simple cucumber command -we need two. It'd be nice if webrat
> could switch between browser types per scenario or per feature. Sigh.

Have you looked at celerity? I'm not sure if webrat has an adapter for
it yet, but it's a 'headless' browser which drives a lot faster than
selenium. Some people on this list are getting a lot of joy out of it.

>>> It'd be kinda cool if there was a sort of before and after for a
>>> than simply once.
>> usually for look-up data... but if you were really concerned about
>> can I ask if your scenarios are written in a declarative or
>> imperative fashion[1]?  If they are written declaratively, or at
>> least partly, then you can specify a lot more behavior in a step
>> without adding too much noise to the scenario.  Another thing I
>> should point out is that you don't need to, and you shouldn't, test
>> everything on the Cucumber level.  For complex views, for example,
>> it may be easier to do RSpec
> _______________________________________________
> rspec-users mailing list
> removed_email_address@domain.invalid
> http://rubyforge.org/mailman/listinfo/rspec-users

Matt W.
http://blog.mattwynne.net
http://www.songkick.com
Ben L. (Guest)
on 2009-05-01 16:09
(Received via mailing list)
On Fri, May 1, 2009 at 12:33 PM, Matt W. <removed_email_address@domain.invalid> 
wrote:

>
> Have you looked at celerity? I'm not sure if webrat has an adapter for it
> yet, but it's a 'headless' browser which drives a lot faster than selenium.
> Some people on this list are getting a lot of joy out of it.


+1 to celerity. You need to jump through some hoops with JRuby/Java but
it
cut the time it takes to run my features by 3-4 times almost.

Ben
Kornelis S. (Guest)
on 2009-05-01 16:13
(Received via mailing list)
Celerity is very cool - when it works.  It didn't work with out messy
combination of javascript libraries, alas.  (Dojo 0.4-ish for legacy
bits, GWT for new bits) - apparently it will work with either of these
frameworks, but for us, with both, it died mysteriously (and we gave
up trying to fix it due to limited time)

- Korny

On Fri, May 1, 2009 at 10:08 PM, Ben L. <removed_email_address@domain.invalid>
wrote:
>
> _______________________________________________
> rspec-users mailing list
> removed_email_address@domain.invalid
> http://rubyforge.org/mailman/listinfo/rspec-users
>



--
Kornelis Sietsma  korny at my surname dot com
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"
Joseph W. (Guest)
on 2009-05-01 16:53
(Received via mailing list)
Ben L. wrote:
> +1 to celerity. You need to jump through some hoops with JRuby/Java
> but it cut the time it takes to run my features by 3-4 times almost.

I would suggest taking a look at Culerity a nice wrapper for Celerity
which takes the headache out of having a non JRuby app use Celerity.

http://github.com/langalex/culerity/tree/master

There is also a Selenium style equivalent -> WebDriver -> a headless
browser. I've not got round to playing with it yet, but it looks nice

http://code.google.com/p/webdriver/

--
Joseph W.
http://blog.josephwilk.net
Ben M. (Guest)
on 2009-05-01 19:54
(Received via mailing list)
Korny S. wrote:
> Celerity is very cool - when it works.  It didn't work with out messy
> combination of javascript libraries, alas.  (Dojo 0.4-ish for legacy
> bits, GWT for new bits) - apparently it will work with either of these
> frameworks, but for us, with both, it died mysteriously (and we gave
> up trying to fix it due to limited time)
>
> - Korny
>

Yeah, I have had similar experiences with Celerity.  To be fair, it is
not Celerity's shortcoming but rather it is HTMLUnit's and Rhino's for
not being able to support all the JS frameworks yet.  If you don't have
a legacy system though I think Celerity is the way to go for JS testing.

-Ben
This topic is locked and can not be replied to.