什么时候自动化TDD方法是最好的方法，什么时候更好只是使用手动测试技术，记录错误，分类，修复等。
另一个问题 – 当我是微软的测试员时，我们强调，开发人员和测试人员有不同的价值，这两个小组之间的紧张关系可以帮助创建一个伟大的产品。 TDD可以打破这个想法，并创造一种情况，开发人员可能不是正确的人，严格找到自己的错误？它可以是自动的，但是似乎有很多方法来写测试，并且一个给定的测试集合是否“证明”质量是可接受的是有问题的。
TDD是一种类似于会计师实行的双重记账纪律的学科。它防止在小的错误。会计师将每次交易输入两次，一次作为信用，一次作为借记。如果没有发生简单错误，那么资产负债表将总和为零。这个零是一个简单的点检，阻止高管去监狱。同样的，程序员在它们的代码之前编写单元测试作为简单的点检。实际上，它们将每个位的代码写两次;一次作为测试，一次作为生产代码。如果测试通过，两位代码是一致的。这两种做法都不能防止更大和更复杂的错误，但这两种做法都是有价值的。
TDD的实践不是真正的测试技术，它是一种开发实践。 TDD中的“测试”一词或多或少是巧合。因此，TDD不是良好测试实践的替代品，而是良好的QA测试人员。事实上，有经验的测试人员独立编写QA测试计划(通常在编写代码的程序员(及其单元测试)之前)是一个非常好的主意。
这是我的偏好(实际上我的激情)，这些独立的QA测试也使用工具，如FitNesse，Selenium或Watir自动化。测试应该容易阅读商务人士，容易执行，完全明确。你应该能够立即运行它们，通常每天多次。
每个系统还需要手动测试。但是，手动测试不应该死机。可以脚本化的测试应该是自动的。你只想在需要人类判断时将人置于循环中。因此，人类应该做exploratory testing，而不是盲目地遵循测试计划。
因此，对单元测试与手动测试的问题的简短回答是没有“对比”。你应该为你编写的绝大多数代码编写自动化的单元测试。您应该有由测试人员编写的自动化质量检查验收测试。你还应该练习战略性探索性手动测试。
