On Sat, Mar 28, 2009 at 9:49 AM, Brandon O.
[email protected] 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->
–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org
