Re: [PhillyOnRails] rspec slides

[Cassius Rosenthal <cassius@xmodulation.com>]

Randy Schmidt wrote:
> > Just as it is frowned upon to rspec
> > whether ActiveRecord can save a record, I think it's equally pointless
> > to rspec whether validates_length_of can return an error.
> >     
>
> I'm just an observer in this conversation, but I think it is pointless
> to test that it can throw an error but I don't think it's pointless to
> test whether or not that validation is in your code.

That is a good point, but do we really need:
it do
 user.login.length.should be_close( 8, 4 )
end
when all that we *want* to write is:
 validates_length_of :login, :within => 4..12

Sure, the spec is only three lines, but it does add up.  At what point 
do we trust the Rails framework to be self-documenting, or defer 
psuedo-documentation to the spec file?  Should we be writing specs for 
dynamic finders?  What about saving an association?

Take this one line:
has_many :dogs
Think of all of the things that this tells you about User and Dog.  Now 
think of how many lines of RSpec you would need to 'specify' the same 
behavior.

Now imagine that you wrote your login.length spec, and then the business 
logic changes -- turns out that the boss likes a login 
"iamthebossandyourarenot."  Now you have to change the spec to be_close( 
14, 10 ) and the model validation to 4..24.  Remember the magic of just 
putting that one line "validates...of" in Rails and having it do what 
you wanted?  Now all of the sudden you are pre-documenting that line, 
and programming in Rails is starting to feel more like a drag.

To take another example, if you have map.resources :dog in routes, then 
do you really need:
route_for(:controller => "dogs", :action => "list").should eql("/dogs")
?  Do you really need that for *every single one* of the RESTful routes 
if you know that you have that one line in routes?  I would argue, "no" 
--  that one line in routes is much better at signifying application 
logic than the 30 or so lines that it takes to specify that in RSpec.

For large apps with long development times, absolutely -- the more 
documentation, the better.  [Although in that case you should be using 
Erlang/Yaws/mnesia anyway (^_^) ]  But for small, quick apps with just a 
few and experienced programmers, I think [opinion flag] that it is more 
pragmatic to eschew full RSpec coverage and stick to specifying the 
logic that is interesting to your app.  Wasted time is wasted money.

I am not alone in thinking this way, either.  Take a look at the 'rSpec 
Basics' peepcode for comparison, and they also mention that the default 
controller specs are excessive.  Excoriations for rSpec abound for the 
google-savvy; but again, I'm actually arguing that you *should* use 
RSpec, just be aware of it's drawbacks.

Thanks!
-Casey
_______________________________________________
To unsubscribe or change your settings, visit:
http://lists.phillyonrails.org/mailman/listinfo/talk