Quoting from Code the Unit Test First:
Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.
Writing a test first limits the amount of over-engineering that you can get away with; when the test passes, you’re done, the feature is complete and that the simplest thing that could possibly work is what was done. However, writing the test first acts in a much more important way to guard against engineering waste: it captures the requirements in such a way as can prove scope creep is occurring. When the scope of the job drifts sufficiently from the encoded requirement, its obvious that something is very wrong. In that way it stops the software itself from bloating and the requirements themselves from getting out of hand.
When there is a well definted specification an executable test suite ensures compliance. Writing this suite after the code hurts in ways too numerous to mention - I know, I took my own free software project offline until there was reasonable test coverage across the application. From now on all new features will be created test-first. Compliance test suites can be easily created when there is a specification. For example, the specification of RSS - versions 0.91, 0.92, 0.93, 1.0, 2.0 and beyond. An automated test suite removes the ambiguity over whether some software implements the spec or not. A simple red or green bar will communicate that fact in a moment
