[rspec-users] Cucumber step definitions vs. RSpec examples
zach.dennis at gmail.com
Sun Mar 29 22:43:57 EDT 2009
On Sat, Mar 28, 2009 at 9:49 AM, Brandon Olivares
<programmer2188 at gmail.com> wrote:
> So, I'm confused. I've been trying to use Cucumber and RSpec, but step
> definitions and RSpec examples just seem to be overlapping. What should go
> in either one of these?
Cucumber is intended to drive out the behaviour of the application and
RSpec is used to drive out the design and behaviour for the components
and objects that make up that application. Cucumber and RSpec are
bound to overlap. They're providing you insights at different levels
about how the application is expected to be working.
> For instance, let's say I'm testing if a form exists on a page. What goes in
> Cucumber and what goes in RSpec?
Does the scenario successfully drive the implementation of the form
and the page its on? If so, I would probably stick with the scenario.
However, if it doesn't then I drop down to a view spec and spec
whatever else the page needs that the scenario doesn't cover.
Scenarios usually don't communicate well the expectations against a
page for showing and hiding information, etc based on permissions or
roles. RSpec works great for this. It provides a wonderful way to
simply and concisely make each of those expectations clear rather than
some strange side-effect of a scenario which is focused on something
> What I did for now is put Webrat methods in the step definitions, like
> fill_in, select, etc, without submitting since I'm not testing processing
> yet; and then put selector matchers in the RSpec examples.
> But I have no idea if that's right. How do you separate these and keep them
> from duplicating one another?
At some level duplication will happen, especially in a web app since
the way you verify the application is working is by
POSTing/GETting/etc and verifying output on the page itself AND it's
also what you have to do when you creating the individual views and
the controllers that make up those pages and respond to those
You may find that a scenario drives you to make a view with a form and
a controller with a #create action to process it. This may be adequate
and you may be able to confidently move forward without writing a view
spec or a controller spec. I know I have found this it the case many
On the flip side, when something additional or conditional occurs that
is usually a good time to drive that with an example in a spec.
I use my scenarios to drive my app from the outside, and then specs to
drive the implementation for each of the underlying pieces. The more
I've practiced the easier and more natural it has become to know when
to do or not to do something. Also, the only way to not have something
feel like it's taking too long is to know your tools. These things
won't just come because you want it to. It takes practice.
Remember to practice.
More information about the rspec-users