Despite all of the stuff you hear about how it will save you time in the future, you’ll know when it breaks, etc, there is one huge benefit that you will soon realize that, to me, outweighs the rest:
It forces you to think about your logic twice. Once when you write your tests, and once again when you write your code.
Unit tests let you get your business rules into code really quickly. If you do all of your business logic in the models, then this is more apparent. For example… you may create a new user, but doing so will mean that he will need to be assigned a default role and some basic rights. You might consider doing that in the user model’s after_save callback.
The smart thing to do (because you can’t easily see this from the web interface) would be to write the test first.
u = User.create :username =>“homer”, :password=>1234
# user should have only one role... guest
assert_equal 1, u.roles.size
# more code would go here to actually verify that the "guest" role is assigned to the user by the callback
Doing that first helps me think about the end result and also helps me decide if that is in fact the way I want to do it… maybe I don’t want to assign the role automatically… maybe I want something else to happen instead.
Just my thoughts… I’m doing my best to convert more people to TDD and am working on a tutorial that helps explain how I use it to build apps… The Peepcode one rocks too so check that out as well.