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
_______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
