The Comfort of Unit Tests

Working on my class project this summer, I decided to bite the bullet and do full unit testing.  I've done unit testing before, but only in small amounts.  In this case, I'm doing something akin to test driven development.  I'm writing the tests very early and for everything.  Not necessarily first, but in very close proximity to when I write the code.  At first it felt painful.  You can't code as fast.  It sucks having to stop and write tests.  Then I started making changes to the design.  This is when it pays to have unit tests.  It was great to make a change, press the "run tests" button, and look for the green bar to appear.  If it didn't, I could easily go fix the issues and continue on.  I didn't have to worry about breaking random things with my changes.  Instead, if the tests passed, I could be confident that everything was still working.  Unit tests are a little like a security blanket.  Just having them makes you feel comfortable.  In the end, I find myself more willing to make changes and to refactor the code.
One of my partners in this project has written some code that I will end up helping out with.  He has no tests for his area.  It's a lot scarier going in there to make changes.  After doing some work, I will have no peace of mind that I haven't subtly changed things.  This also points out another benefit of unit tests.  It makes life a lot easier for the next person.  It's not too hard to keep all of your own code in your head and know what effects changes are likely to have.  It's very difficult to do the same with someone else's code.  I want the ability to make what looks like an obvious change without having to read every piece of someone else's code first.  Creating unit tests makes life a lot easier for whoever has to maintain the code later.
This brings up a use for unit tests that is mentioned in the literature but is not often considered in the real world.  When you are asked to change "scary" code that doesn't have any unit tests, consider spending the first part of your schedule writing those tests.  Not tests for the new code, but tests for the code as it originally exists.  Once you have a comprehensive suite of tests, you can make changes with peace of mind.

http://blogs.msdn.com/b/steverowe/archive/2007/08/01/the-comfort-of-unit-tests.aspx