[rspec-users] Cucumber for large projects
f.mischa at gmail.com
Tue Mar 3 04:08:54 EST 2009
Speed will possibly become a big issue once you get above 1-2k steps or so.
Testjour was written to solve this:
While I haven't been able to use it myself, since I work mostly from home,
it apparently radically reduces the time it takes to run features.
The only other tip I have for using cucumber in big projects is to make sure
that you stay on top of small changes to code that don't break features, but
over time end up changing what is happening to the point that, while the
test passes, it is no longer testing what you think it is testing. So, like
Matt said, it's a good idea to keep on top of things. However, this is a
minor issue and not cucumber specific.
On Mon, Mar 2, 2009 at 5:17 PM, Matt Wynne <matt at mattwynne.net> wrote:
> On 26 Feb 2009, at 15:33, Tom ten Thij wrote:
> We will be using Cucumber for a fairly large project. Are there any
>> areas that cucumber is lacking when there are many scenarios?
>> I believe the best candidate for showing our client the scenario
>> results is the html output. It strikes me that that becomes fairly
>> to hide all passing scenarios / features would be useful. Is there any
>> work being done on this?
>> In which areas could we help cucumber accommodate for large projects?
> Hi Tom,
> At Songkick.com, we currently have 635 scenarios in our Cucumber tests, and
> while we've had a few issues, the ROI has definitely been worth it.
> At the moment, IMO, the tools for feeding back the features to
> non-technical people are pretty immature. My colleague Dan Lucraft wrote a
> tool which produces a nicely-formatted PDF document from your features
> folder which is great, but won't work with the new version (0.2) of
> Cucumber when it's released as the API against which such formatters are
> written has undergone some significant changes for the new version.
> Once this stuff stabilises into the 0.2 release I expect more effort will
> be put into such tools, as the changes Aslak has made will make it much
> easier to write them. Check out the brave vision for the new HTML formatter:
> Other than that, you'll be likely to hit some issues just to do with
> managing the large number of specifications, but to be honest this has
> surprised me by being much easier than expected. The amount of code you
> actually write in the step definitions is minimal, especially if you're
> using Rails and something like factory_girl, so with a bit of regular
> re-factoring it's really easy to stay on top of it. We made a call early on
> to split our features folder into sub-folders named after the type of user,
> which has worked well for us:
> That's helped us to keep things tidy, but there are obviously other ways to
> slice things up too. Are you planning to test the browser too (with selenium
> / watir / etc) or just from the HTTP requests down? Assuming you're building
> a web app of course... :)
> Matt Wynne
> rspec-users mailing list
> rspec-users at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users