尽管单元测试在需要 API 较强的大型项目上看起来很有效（例如开发 .Net 框架 API 等），但在小型项目上可能会显得有些过度。
自动化 TDD 方法什么时候是最佳选择，何时使用手动测试技术、记录错误、分类、修复等方式更好。
另一个问题——当我在微软担任测试员时，我们被强调要让开发人员和测试人员分别负责，并且这两个团队之间的紧张关系可以帮助创造出优秀的产品。但是，TDD 是否会打破这一想法，并且是否会导致开发人员无法彻底找到自己的错误？虽然这是自动化的，但似乎有许多编写测试的方法，而且对于一组给定的测试来说，“证明”质量是否可接受是值得怀疑的。
我希望这些独立的QA测试也能使用像FitNesse, Selenium, 或者Watir这样的工具进行自动化。测试应该易于被业务人员理解，易于执行，并且绝对明确无误。通常每天可以多次运行测试。
每个系统也需要手动测试。然而，手动测试不应该是例行公事。可以脚本化的测试应该自动化。只有在需要人类判断时才应该将人类放入循环中。因此，人类应该进行exploratory testing，而不是盲目地遵循测试计划。
因此，关于何时进行单元测试与手动测试的问题的简短答案是没有"对比"。你应该首先为你编写的绝大部分代码编写自动化单元测试。你应该让测试人员编写自动化QA验收测试。同时你也应该实践战略性的探索性手动测试。
单元测试并不意味着取代功能/组件测试。单元测试的重点非常窄，因此它们不会涉及数据库、外部服务等。集成测试会这样做，但您可以让它们聚焦在特定点上。总之，在特定问题上的答案是它们不能替换那些手动测试。
更新1：请注意，如果开发人员正在创建自动化的功能测试，则仍然需要审查其是否具有适当的覆盖范围，并根据需要进行补充。一些开发人员使用他们的“单元”测试框架创建自动化的功能测试，因为无论单元测试如何，他们仍然必须进行冒烟测试，而这确实有助于自动化 :)
更新2：对于小项目来说，单元测试并不过度，自动化冒烟测试或使用TDD也不过度。过度的是让团队在小项目上第一次尝试任何其中一项。这些工作都有一个相关的学习曲线（特别是单元测试或TDD），并且并不总是第一次正确完成。您还需要某个已经做了一段时间的人参与其中，以帮助避免陷阱并克服开始时不明显的一些编码挑战。问题是团队通常不具备这些技能。
测试驱动开发（TDD）是可行的情况下最佳方法。 TDD测试是自动化的，通过代码覆盖率可以量化，并且是确保代码质量的可靠方法。
与TDD相比，手动测试需要大量时间并容易出现人为错误。
并不是说TDD只由开发人员进行测试。开发人员应该负责编写测试框架的一部分。 QA应该负责更大的部分。开发人员按照他们想要测试的方式测试API。 QA以我从未想到的方式测试API，并执行看似疯狂但实际上客户会执行的操作。
开发者 vs. 测试人员 开发者在测试自己的代码方面往往表现不佳：原因有心理、技术和经济等方面 - 测试人员通常比开发者便宜。但开发者可以尽自己的一份力，让测试变得更容易。TDD使测试成为程序构建的固有部分，而不仅仅是一个事后想法，这才是TDD的真正价值。
关于测试的另一个有趣的点：100%的覆盖率是没有意义的。统计学上，错误遵循80:20规则——大多数错误都在代码的小部分中发现。一些研究表明，这甚至更加明显——测试应该集中在错误出现的地方。
(1) 编程生产力琼斯1986年等，引自《代码大全》第二版。但正如其他人所说的，单元测试只是测试的一部分，集成、回归和系统测试也可以-至少部分地-自动化。
我对结果的解释是：“许多双眼睛”具有最佳的缺陷检测能力，但前提是您必须有一些正式的流程使他们真正去看。
我相信将QA /测试人员的专业知识（定义测试/验收标准）与TDD概念相结合是可能的，即使用开发人员拥有的API（而不是GUI或HTTP /消息接口）来驱动测试应用程序。
仍然需要独立的QA人员，但是现代测试工具（如FitNesse，Selenium和Twist）使得我们不再需要庞大的手动测试团队。
单元测试只能做到这个程度（所有其他类型的测试也是如此）。我把测试看作是一种“筛子”过程。每种不同类型的测试都像是你放在开发过程出口下面的筛子。流出来的东西（希望）大部分是你软件产品的特性，但它也包含了错误。这些错误有很多不同的形状和大小。
有些错误很容易找到，因为它们很大或者会被任何一种筛子捕捉到。另一方面，有些错误很光滑、闪亮，或者没有很多钩子，所以它们很容易从一种筛子中滑过去。不同类型的筛子可能有不同形状或大小的孔，因此它将能够捕捉不同类型的错误。你拥有的筛子越多，你就能捕捉到更多的错误。
显然，你拥有的筛子越多，通过的特性就越慢，因此你需要尝试找到一个平衡点，既不要花费太多时间进行测试，也不能让你无法发布任何软件。
