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

[Brandon Olivares]

> -----Original Message-----
> From: rspec-users-bounces at rubyforge.org [mailto:rspec-users-
> bounces at rubyforge.org] On Behalf Of Stephen Eley
> Sent: Sunday, March 29, 2009 3:47 PM
> To: rspec-users
> Subject: Re: [rspec-users] Cucumber step definitions vs. RSpec examples
> 
> 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.
> 

Thank you very much. That is much more understandable. This made me realize
I forgot the controller testing for the feature I'm talking about.


> 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.)
> 

Yeah, that's what I'm worried about. I wrote probably 5 examples just to
test the existence of one field and ensure it had the options I wanted. I'm
worried about it taking way too long. But I do like the security provided by
extensive unit tests.

Thanks,
Brandon