[rspec-users] Cucumber step definitions vs. RSpec examples

Zach Dennis zach.dennis at gmail.com
Sun Mar 29 23:09:58 EDT 2009

On Sun, Mar 29, 2009 at 3:47 PM, Stephen Eley <sfeley at gmail.com> wrote:
> 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?
> This is a subjective judgment call that doesn't have an absolute
> 'right' answer.  Ask a dozen programmers how they test and you're
> likely to get at least three dozen answers.
> I believe the purists would say that the duplication is a feature.
> The gist of this point of view is that RSpec's main strength is on the
> unit testing level: you want to test that model code works separate
> from your controller code, and your controller code separate from your
> view code.  Then if one fails, you know exactly what class went wrong
> and what to fix.
> Cucumber's main strength is on the acceptance or integration level:
> you want to make sure it all comes together correctly and creates the
> right application behavior, which is very hard to prove with unit
> testing alone.  But if you _only_ did Cucumber tests, your test to see
> if a form exists on a page (to use your example) would be too broad.
> If it failed, where do you look first?  Is the view broken?  The
> controller code?  Do you even have a model for the view to operate on?
>  Etc.
> So you need to have bot levels.  You specify your overall behavior
> with Cucumber, then you specify the isolated behaviors of the pieces
> to make that work, and then you write your code.  That's the
> full-round-trip, complete by-the-RSpec-book BDD answer.
> My own view...  Well, my view is that I've tried that and been driven
> nuts by it.  Writing specs for controllers and views can take me many
> times longer than writing the code.  Mocking out the models for
> controllers is frustrating and fragile to me, and view specs are just
> obvious and tedious.  I don't have any _fun_ writing those specs.  And
> if I'm not having fun, I find myself not motivated to program.
> So I stopped writing those specs, and now I mostly just write model
> specs and Cucumber features.  It usually doesn't take that long for me
> to look at a failing Cucumber test and figure out what went wrong --
> from the failure text, a stacktrace, or sometimes just manually
> running the action and eyeballing it.  Sometimes, if the controller
> action is unusual, I will write a spec for it, but only if my own
> instincts tell me it's warranted.  (Or if something failed in an odd
> way and I want to make sure that doesn't happen again.)
> That's my current answer based on past experience.  Next month I might
> have a different way of doing things.  I'm not going to make the case
> here that I'm right and you should never write controller/view specs
> for ordinary actions.  (If nothing else, doing it a bunch of times --
> and getting some things wrong, then fixing them -- is a great way to
> learn how controllers and views really work.)
> I think the real answer is to try it a few different ways, decide what
> works within your comfort level *and* leads to good code, and let
> yourself experiment.  And then, if you develop an effective working
> pattern down the road that you think makes good general sense, share
> it with the community as one more way of doing things.   >8->

I like a lot of what Steve is saying. To summarize and communicate in
my own way...

It is good to know how and when to do something. Like writing view
specs and controller specs. If you don't know how then you'll never
know when. Sometimes learning to take small steps seems ridiculous,
but it's by being able to work in small steps that you can be
confident about making larger ones.

Here are three questions I ask myself when I get frustrated:

 1 - Am I doing it wrong?
 2 - Should I be doing this in the first place?
 3 - Am I experiencing a skills deficiency?

Usually I think it's #1 and then I quickly jump to #2 when I don't get
it resolved in 5 minutes of googling. And then I find out a day later
it was because of #3 and I needed to go home and practice a little
more so I better understood what I was doing, why I was doing it, and
how I could leverage the tools to make it easier.

We all learn to make good decisions by first making bad ones, and
practice lets us do that w/o putting giant turds in an application's
production codebase.

Zach Dennis

More information about the rspec-users mailing list