[rspec-users] Working outside-in with Cucumber and RSpec

Pat Maddox pergesu at gmail.com
Sat Oct 25 17:37:25 EDT 2008


> If I say we're going to
> skip controller specs because they don't add enough value, how do I
> know that won't be interpreted as "controller specs are too hard,
> don't write specs when it's hard"?

I have a three-headed defense of rarely writing controller specs
anymore:

* Controllers are already exercised by cucumber
* Most of the logic is provided by the framework.
* Controllers tend to be procedural instead of OO

The first one should be obvious.  As for the second, since I'm not
actually writing most of the code, I'm not that worried about it
breaking.

Procedural code is no fun to test.  You have to use a lot of mocks, and
your example looks more or less the same as the production code.  Blech.
Rails controllers don't encapsulate state or iteration, the only
encapsulation-worthy behavior usually is a simple if statement.
Controllers also typically aren't very cohesive, you're never going to
call more than one method on them.  Put simply, controllers, as used in
Rails, are a collection of transaction scripts grouped together by the
resource on which they operate.

Now, when I don't write cucumber features, I absolutely do write
controller specs.  But I'll have those hit the db, with integrate_views
turned on, acting essentially as an integration test.  The thing is,
there isn't a lot of value in writing both features and controller
specs, unless your controllers have some pretty complex logic (which
they shouldn't when using Rails!)

So I guess that were I to be teaching someone this stuff, I would
explain the benefits of testing, and evaluate how controller specs add
value.  Specifically, they don't add regression value over features, and
they provide marginal design value, particularly if you follow typical
Rails controller patterns.  I would explain that I don't see much
benefit to the controller specs, and that they're kinda tough to test
because they're not very OO.  And I'd use that as an opportunity to
notice smells - when you're writing specs and it's difficult, and you
control all the code, then your code could probably use some design
improvements.

But yeah, I like working outside-in :)

Pat


More information about the rspec-users mailing list