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: