[rspec-users] My very fist spec file (not sure what's wrong..)

Stephen Eley sfeley at gmail.com
Tue Jul 21 23:43:35 EDT 2009

2009/7/21 internetchris <chris at silhouettesolutions.net>:
> When writing specs for controllers am I always
> going to mock the model? Are controllers always isolated from the
> actual model?

Hi Chris,

Pretty insightful of you.  This is one of those philosophical
questions that tends to keep coming up.  The only valid answer to it
is "YMMV" -- everyone seems to have a different comfort level with how
this is done.

David Chelimsky advocates strong isolation and full model mocking for
controller specs.  That's why you see it in the RSpec book and the
official RSpec site.  Yehuda Katz pushes a more integrated approach of
spec'ing the *request* from soup to nuts rather than the controller's
code base; you can see that in Merb's testing helpers, or in this
video from last year's RubyConf:

Both schools of thought have pros and cons, and both camps have their
followers.  And then some people take an approach somewhere in the
middle, or use Cucumber exclusively, or use macro frameworks like
Shoulda or mock_resourceful, or do their own thing, or just throw up
their hands and don't test controller flow at all.

Having said that -- I'll tell you what *I* do.  I used to spec
everything.  When I was learning RSpec I was quite zealous about it,
and I think that was a good experence. These days, though, I skip
specs for most of my controllers and declare the integration in
Cucumber features instead. I won't say that I *never* write controller
specs, but if I do it's usually because that controller does something
unusual.  Maybe it pulls in a couple of different models, or it needs
to reply to "/login" instead of the default "person_sessions/new" or
it has a filter to load tabs.  I'll spec that sort of interesting
behavior.  If it's just a straight, looks-like-scaffold-code REST
controller, I usually don't spec it.  And I certainly don't write
stubs for it.

My typical feeling is that all that stubbing to set up controller
isolation is a lot of work for small risk.  90% of all Rails
controllers are pretty nearly identical to each other, and the "cookie
cutter" RESTful controller model is simple, well-understood and
thoroughly tested in the Rails core code.  If it does break on me it's
probably because I made some sort of dependency error, like forgetting
to declare the route or using the wrong path in my views.  That sort
of thing turns up in my integration testing (i.e. my Cucumber
features) and is always pretty easy to spot and fix.  I don't really
gain anything by writing specs for generic execution paths that are
already tested in Rails itself.

That's my approach.  I'm not going to claim it's the _best_ -- just
that it's where my comfort level is right now.  The way I do things
has changed before, and it will probably change again.  You'll find
your own way of doing things too; and that's a Good Thing.

In the meantime, you can't really lose by following the steps from the
RSpec Book as you're starting out.  Even if you do decide that it's
too much overhead later on, having had the practice and developed the
discipline will help you to make smart decisions and develop your own
effective style.

Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine

More information about the rspec-users mailing list