Hey guys, I appreciate the insight, and this brings me to my next question, and actually the next chapter in the book (specing models). I read that "most" developers shy away from view specs (for the most part - not always), and then if I understand both of you correctly....each of you tend to "do as little" with controller specs as absolutely necessary. So if that's the case is the main use of rspec within a rails app for the model and validation testing? I'm sure I will gain a little more insight on this as I progress into the next chapter, but it begged to be asked. In fact it's probably too much of a sweeping statement. As I think about this a little more I can see how each of these "little" things that rspec is used for add up to some major tools to help ensure good solid code. Just the re-factoring element which is more a philosophy than it is an actual syntactical element makes for nice DRY systems.
I guess this is more of a rhetorical post, but if someone wants to add their two cents go ahead. I have been taking my time through the Rspec book making sure I understand each element. I'm forcing myself to "really" understand it so I can develop better apps. Thanks again! Chris On Jul 21, 9:43 pm, Stephen Eley <sfe...@gmail.com> wrote: > 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-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
