2009/7/21 internetchris <ch...@silhouettesolutions.net>: > When writing specs for controllers am I always > going to mock the model? Are controllers always isolated from the > actual model?
Hi Chris, Pretty insightful of you. This is one of those philosophical questions that tends to keep coming up. The only valid answer to it is "YMMV" -- everyone seems to have a different comfort level with how this is done. David Chelimsky advocates strong isolation and full model mocking for controller specs. That's why you see it in the RSpec book and the official RSpec site. Yehuda Katz pushes a more integrated approach of spec'ing the *request* from soup to nuts rather than the controller's code base; you can see that in Merb's testing helpers, or in this video from last year's RubyConf: http://rubyconf2008.confreaks.com/writing-code-that-doesnt-suck.html Both schools of thought have pros and cons, and both camps have their followers. And then some people take an approach somewhere in the middle, or use Cucumber exclusively, or use macro frameworks like Shoulda or mock_resourceful, or do their own thing, or just throw up their hands and don't test controller flow at all. Having said that -- I'll tell you what *I* do. I used to spec everything. When I was learning RSpec I was quite zealous about it, and I think that was a good experence. These days, though, I skip specs for most of my controllers and declare the integration in Cucumber features instead. I won't say that I *never* write controller specs, but if I do it's usually because that controller does something unusual. Maybe it pulls in a couple of different models, or it needs to reply to "/login" instead of the default "person_sessions/new" or it has a filter to load tabs. I'll spec that sort of interesting behavior. If it's just a straight, looks-like-scaffold-code REST controller, I usually don't spec it. And I certainly don't write stubs for it. My typical feeling is that all that stubbing to set up controller isolation is a lot of work for small risk. 90% of all Rails controllers are pretty nearly identical to each other, and the "cookie cutter" RESTful controller model is simple, well-understood and thoroughly tested in the Rails core code. If it does break on me it's probably because I made some sort of dependency error, like forgetting to declare the route or using the wrong path in my views. That sort of thing turns up in my integration testing (i.e. my Cucumber features) and is always pretty easy to spot and fix. I don't really gain anything by writing specs for generic execution paths that are already tested in Rails itself. That's my approach. I'm not going to claim it's the _best_ -- just that it's where my comfort level is right now. The way I do things has changed before, and it will probably change again. You'll find your own way of doing things too; and that's a Good Thing. In the meantime, you can't really lose by following the steps from the RSpec Book as you're starting out. Even if you do decide that it's too much overhead later on, having had the practice and developed the discipline will help you to make smart decisions and develop your own effective style. -- Have Fun, Steve Eley (sfe...@gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
