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 <b...@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@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
