[rspec-users] My very fist spec file (not sure what's wrong..)

internetchris chris at silhouettesolutions.net
Wed Jul 22 00:36:50 EDT 2009

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

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!


On Jul 21, 9:43 pm, Stephen Eley <sfe... at gmail.com> wrote:
> 2009/7/21 internetchris <ch... at 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... at gmail.com)
>    ESCAPE POD - The Science Fiction Podcast Magazine
>    http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list