There have been many discussions about the appropriateness of the term "tests" in describing the unit tests created during test driven development. Most of the debate has centered around the overloaded use of the term "test". For many, the expectation of testing is to discover bugs. There are also many forms of testing, such as usability testing and exploratory testing. Generally, I think the traditional role of a tester (and most forms of testing) are about the act of discovery.

Test Driven Development is more about verification than discovery and I think this is one core motivation of TDD. In TDD, you specify your expectation first, then write code to satisfy it; the test verifies this contract.

Though I am not making any grand revelation, I think there is a subtle importance in the distinction I've made. I was recently asked about test coverage, completeness and TDD. There has been a lot of interest and research regarding test coverage and completeness. There have even been attempts to provide formal proofs of correctness for software programs. The desire is to have a verification mechanism. TDD does provide good test coverage of code bases, though it doesn't guarantee there will be no bugs or other unexpected behavior. TDD simply provides a mechanism for verifying that declared expectations have been satisfied.

Since I think testing is more about discovery, I think it is a very different type of activity. One of the challenges of testing is that you never know when you are done. Therefore, it is somewhat pointless to ask about test coverage or completeness. How would you define "complete"? The act of testing is about the discovery and refinement of expectations. As expectations are discovered, a verification can be captured, satisfied and automated.

There has been a lot of debate regarding the need of manual testing compared to automated tests. For me, if I use the moniker verification, there is no debate. Verification operations should be automated; testing should not.