I disagree with some of the points made here.<p>> Design aid: Writing tests first gives you a clearer perspective on the ideal API design.<p>Unit tests are usually too low-level to give feedback into the API design. My experience is that functional tests, based on use case scenarios, give much better feedback.<p>Standard TDD-based design doesn't really have a way to specify which is part of the "public" API vs. the testing API. Instead, it usually implies that everything is part of the public API, which locks in the architecture rather early. Are there common practices for distinguishing between the two?<p>> Feature documentation (for developers): Test descriptions enshrine in code every implemented feature requirement.<p>Unit tests rarely encode performance requirements. For example, you might have a feature requirement that the code process 10 M records in 2 minutes, or that a given implementation must have worst-case N log N performance. While it's possible to use a unit test framework to write these sorts of functional tests, they are not unit tests.<p>> Manual QA is error prone. In my experience, it’s impossible for a developer to remember all features that need testing after making a change to refactor, add new features, or remove features.<p>Manual QA is a skill in it own right. This is why you have QA staff, who develop and implement a testing plan. Developers rarely have QA experience, so it's not surprising that they would have more problems.<p>> Automated QA affords the opportunity to automatically prevent broken builds from being deployed to production<p>Agreed, but as James Coplien pointed out in "Why Most Unit Testing is Waste":<p>> You’ll probably get better return on your investment by automating integration tests, bug regression tests, and system tests than by automating unit tests.