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

Zach Dennis zach.dennis at gmail.com
Tue Oct 28 21:39:58 EDT 2008

I forgot to add that until there is a new way to handle the role that
controllers currently are responsible for, I would probably teach someone
how to write good controllers and controller examples. I would also allow
them to experience the pain that comes with trying to write bloated
controller actions and filters so they can see the warning signs that come
with the controller specs. This facilitates reflection and discussion, and
allows them to grow while I'm there.
More generally, as a teacher we have a lot of experience and reference
points that we draw on. It can be easy to overlook this and to just have
everyone do what we do, but then they never get the "why" part of it because
that's still up in our heads.

On Tue, Oct 28, 2008 at 9:27 PM, Zach Dennis <zach.dennis at gmail.com> wrote:

> 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
> time.
> 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
> to.
> 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
> http://www.continuousthinking.com
> http://www.mutuallyhuman.com

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

More information about the rspec-users mailing list