[rspec-users] Before and After blocks for individual feature files?

Matt Wynne matt at mattwynne.net
Fri May 1 07:33:10 EDT 2009


On 1 May 2009, at 03:32, Julian Leviston 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.

>
>
> Blog: http://random8.zenunit.com/
> Learn rails: http://sensei.zenunit.com/
>
> On 29/04/2009, at 3:47 PM, Ben Mabey <ben at benmabey.com> wrote:
>
>> Julian Leviston 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
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com



More information about the rspec-users mailing list