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