A lot of times when you're introduced to Unit Testing, you're sold on the fact that it's the best way to have regression testing in place. That's 100% accurate. Whether you practice Test Driven Development or take a test-after (test-last, POUT, whatever you want to call it….) approach, creating unit tests allows you to test changes in your code and make sure that bug fix, change or new feature hasn't broken any functionality. However, one of the great added values to Unit Testing that often doesn't get as much attention as it should, although always present, is documentation.
How many times have you come across some piece of code that you needed to change and was wondering why you did something the way you did? Talk to your colleagues, look for documentation, look for comments, only to find nobody recalls anything and not one word jotted down anywhere about it. This is where a good suite of unit tests come in handy. If you have tests that verify behavior of your code, and also make sure that your code coverage is quite high (over 80%), you have a good chance to find out why something is coded in a particular way. Even if you don't name your tests with a "specification orientated" convention, it is still very valuable to know that when you make that change, your tests still run. And the higher the code coverage, the less chances are that something will fail on deployment.
So whether or not you or your colleagues recall why you did something in a particular way, you might not need to if you document your code with tests.
