[rspec-users] Cucumber step definitions vs. RSpec examples
programmer2188 at gmail.com
Sun Mar 29 17:38:08 EDT 2009
> -----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?
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.
More information about the rspec-users