The following quote comes from the abstract of Steve Freeman's and Nat Pryce's workshop "Are Your Tests Really Driving Your Development?" they're going to present at the XP Day conference in London (Emphasis mine):
Everybody knows that TDD stands for Test Driven Development. However, people too often concentrate on the words "Test" and "Development" and don't consider the what the word "Driven" really implies. For tests to drive development they must do more than just test that code performs its required functionality: they must clearly express that required functionality to the reader. That is, they must be clear specifications of the required functionality. Tests that are not written with their role as specifications in mind can be very confusing to read. The difficulty in understanding what they are testing can greatly reduce the velocity at which a codebase can be changed.
That's some awesome text right there and quite nicely describes why TDD done "right" is not just about writing unit tests or just about writing unit tests before the code. And why nurturing our test code is as vital as nurturing our production code.
While I agree on the extremely important point of taking good care of test code, I find the argument of Brian Marick on the difference between tests and specifications convincing.
Nowadays I think of my "test methods" as examples of the desired behaviour of the program. TDD is soo 2001, BDD is the new pink, and at its best with the example-driven twist ;)