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

Zach Dennis zach.dennis at gmail.com
Tue Oct 28 21:27:31 EDT 2008

Controllers are such a funny thing. Right now they are necessary evil. Once
you start feeling pain with controllers you start changing your thinking.
Somehow everyone who starts learning Rails ends up with bloated controllers
even if they've read all of the posts and articles on "skinny
controllers/fat models".

IME, only then do people start rethinking the path they've taken. Now they
start to roll up their sleeves and find out how they can really make skinny
controllers and fat models.

So they go write skinny controllers (in terms of what goes inside each
action) and really bloated models. And the cycle repeats itself. Now they
write skinny controllers (again in terms of what goes inside each action)
and relatively chunky models. The key here is that they now don't shove
everything into "one" model. They start using more than one if necessary.
And sometimes it happens to be an AR object and other times just a PORO.

Lastly, sometime in all of this they get bitten by the dormant monster that
are controller filters and controller mixins. *Sigh*, now controller
examples really suck to maintain and write.

It seems like 1 out every 3 Rails developers will move the unnecessary logic
that makes up these filters and mixins into their own objects, and they let
the controller just use those objects, rather than having the logic end up
embedded into the controller itself. This is what I do.

At the end of this cycle folks start writing cookie cutter controller
actions since their controllers really are simple and skinny. The controller
actions all look like they've been generated from the same template. And so
do our controller specs. Now we can write textmate snippets, generators,
etc. to do the tedious work for us, and we can stop doing it from hand each

And at this point this is a tell-tale sign that an abstraction is needed.
Ultimately, more than an abstraction probably. I think we need a shift in
how we think about mapping incoming requests to real objects doing real work
is in order. I know that there are plugins like make_resourceful which try
to eliminate some of pain that comes with redundancy, but this fills a void
in the current controller implementation in Rails right now. We need bigger
shifts in thinking to occur IMO. Anyways back on topic...

Mock-based examples will never provide anywhere near the value as a
regression test as an integration test (ie: cucumber features/acceptance
tests). That's ok. They're not intended to.

Integration tests will never provide anywhere near the value as design and
discovery agents as object level examples. That's ok. They're not intended

I agree with Ben Mabey that about receiving value from having controller
examples. It helps the design of the controller stay simple and clean over
time. To me this is important, and I value it more than the few minutes it
takes me to write some controller examples.

I disagree with everyone who doesn't write view specs. :) For me, the risk
of not having them is too high compared to the few minutes it takes to spec
a view. Granted, there is overlap between features and view specs, but I
consider that par for the course.

Zach Dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081028/ede7d905/attachment.html>

More information about the rspec-users mailing list