虽然单元测试似乎对API需要具有工业实力的大型项目（例如.Net框架API的开发等）有效，但似乎对小型项目来说可能过度。
什么时候自动TDD方法是最好的方式，什么时候可以更好地使用手动测试技术，记录错误，分类，修复它们等。
另一个问题 - 当我在微软的测试人员时，向我们强调，让开发人员和测试人员成为不同的人是有价值的，并且这两个群体之间的紧张关系可以帮助创建一个伟大的产品结束。 TDD可以打破这个想法并创造一种情况，开发人员可能不是严格找到自己错误的合适人选吗？它可能是自动化的，但似乎有很多方法可以编写测试，并且一组给定的测试是否“证明”质量是否可接受是值得怀疑的。
答案 0 :(得分：65)
TDD的有效性与项目规模无关。即使是最小的编程练习，我也会练习the three laws of TDD。测试不需要花费太多时间来编写，并且它们节省了大量的调试时间。它们还允许我重构代码而不用担心破坏任何东西。
TDD是一门类似于会计师实行的双重记账规则的学科。它可以防止小错误。会计师将每次交易两次;曾经作为信用卡，一次作为借记卡。如果没有做出简单的错误，那么资产负债表将总和为零。零是一个简单的抽查，以防止高管入狱。同样，程序员在代码之前编写单元测试作为简单的抽查。实际上，他们将每一位代码写入两次;一次作为测试，一次作为生产代码。如果测试通过，那么两位代码是一致的。这两种做法都不能防止更大，更复杂的错误，但这两种做法都是有价值的。
TDD的实践并不是真正的测试技术，而是一种开发实践。 TDD中的“测试”一词或多或少是巧合。因此，TDD不能替代良好的测试实践和良好的QA测试人员。实际上，让经验丰富的测试人员独立地（并且通常在编程代码）编写代码（以及他们的单元测试）之前编写QA测试计划是一个非常好的主意。
我最喜欢（实际上是我的热情）这些独立的质量检查测试也是使用FitNesse，Selenium或Watir等工具自动完成的。测试应该易于商务人士阅读，易于执行，并且完全明确。您应该能够立刻运行它们，通常每天多次。
每个系统也需要手动测试。但是，手动测试永远不应该死记硬背。可以自动编写可以编写脚本的测试。你只想在需要人类判断时把人放在循环中。因此，人类应该exploratory testing，而不是盲目地遵循测试计划。
因此，对于何时进行单元测试与手动测试的问题的简短回答是没有“对比”。您应该为您编写的绝大多数代码编写 first 的自动单元测试。您应该具有由测试人员编写的自动化QA验收测试。您还应该进行战略性探索性手动测试。
答案 1 :(得分：7)
单元测试不是要替换功能/组件测试。单元测试非常集中，因此它们不会影响数据库，外部服务等。集成测试可以实现这一点，但您可以让它们真正专注。最重要的是，就具体问题而言，答案是他们不会取代那些手动测试。 现在，自动化功能测试+自动化组件测试肯定可以取代手动测试。这将取决于很多项目及其实际做法的方法。
更新1：请注意，如果开发人员正在创建自动功能测试，您仍需要查看那些具有适当覆盖范围的内容，并根据需要对其进行补充。一些开发人员使用他们的“单元”测试框架创建自动化功能测试，因为无论单元测试如何，他们仍然必须进行冒烟测试，这真的有助于自动化:)
更新2：单个测试对于小型项目来说并不过分，也不会自动进行冒烟测试或使用TDD。什么是矫枉过正是让团队第一次在这个小项目上做任何这样的事情。做任何这些都有相关的学习曲线（特别是单元测试或TDD），并不总是一开始就完成。你也希望有人在一段时间内参与其中，帮助避免陷阱并克服一些编码挑战，这些挑战在开始时并不明显。问题是团队拥有这些技能并不常见。
答案 2 :(得分：3)
手动测试需要大量时间（与TDD相比）并且存在人为错误。
没有什么可说TDD意味着只有开发人员测试。开发人员应负责编写测试框架的一定百分比。质量保证应该负责更大的部分。开发人员以他们想要测试API的方式测试API。质量检查以我真正想不到的方式测试API，做的事情看似疯狂，实际上是由客户完成的。
答案 3 :(得分：3)
我会说单元测试是程序员帮助回答的问题：
这段代码是否符合我的想法 呢？
这是一个他们需要自问的问题。程序员喜欢自动化他们所做的任何事情。
单独的测试团队需要回答另一个问题： -
这个系统是否符合我（以及最终用户）的期望 去做？还是让我感到惊讶？
有一大堆与程序员有关的错误，或者设计师对单元测试永远不会拾取的正确内容有不同的看法。
答案 4 :(得分：3)
根据各项目的研究（1），单元测试发现 15..50％的缺陷（平均为30％）。这并不能使它们成为你武器库中最糟糕的bug发现者，也不会成为银弹。 没有银子弹，任何好的QA策略都包含多种技术。
自动运行的测试运行得更频繁，因此它会更早发现缺陷并极大地降低这些缺点 - 这是测试自动化的真正价值。
明智地投资你的资源，先选择低调的果实 我发现自动化测试最容易编写和维护代码的小单元 - 隔离的函数和类。最终用户功能更容易手动测试 - 一个好的测试人员会发现超出所需测试的许多奇怪之处。不要将它们相互对立，你需要两者。
开发人员与测试人员开发人员在测试他们自己的代码方面非常糟糕：理由是心理，技术和最后经济 - 测试人员通常比开发人员便宜。但开发人员可以尽自己的一份力量，让测试更容易。 TDD使测试成为程序构建的一个固有部分，而不仅仅是事后的想法，这是TDD的真正价值。
关于测试的另一个有趣的观点：100％覆盖率没有意义。从统计上来说，错误遵循80:20的规则 - 大多数错误都存在于小部分代码中。 Some studies表明这更加尖锐 - 测试应该集中在发生错误的地方。
（1）编程生产力Jones 1986 u.a.，引自Code Complete，2nd。编辑。但正如其他人所说的那样，单元测试只是测试的一部分，集成，回归和系统测试也可以 - 部分地 - 自动化。
我对结果的解释：“很多眼睛”有最好的缺陷检测，但只有你有一些正式的过程才能让它们真正看起来。
答案 5 :(得分：1)
单元测试只能到目前为止（所有其他类型的测试也是如此）。我将测试视为一种“筛选”过程。每种不同类型的测试都像筛子一样放在开发过程的出口处。出来的东西（希望）主要是针对您的软件产品的功能，但它也包含错误。这些虫子有很多不同的形状和大小。
有些臭虫很容易找到，因为它们很大或基本上都被任何筛子捕获。另一方面，一些虫子光滑而有光泽，或者两侧没有很多钩子，所以它们很容易穿过一种筛子。不同类型的筛子可能具有不同形状或尺寸的孔，因此它能够捕获不同类型的虫子。你拥有的筛子越多，你捕获的虫子就越多。
显然，你拥有的筛子越多，功能也越慢，所以你会想要找到一个快乐的媒介，你不会花太多时间来测试你永远不会发布任何软件。
答案 6 :(得分：1)
自动单元测试的最好点（IMO）是当你改变（改进，重构）现有代码时，很容易测试你没有破坏它。一次又一次地手动测试一切都会很乏味。
答案 7 :(得分：1)
每个应用程序都经过测试。
某些应用程序会以我的代码编译的形式进行测试，并且代码显示为功能。
某些应用程序通过单元测试进行测试。一些开发人员对于故障的单元测试，TDD和代码覆盖是虔诚的。像所有事情一样，太多往往是坏事。
有些应用程序幸运地通过 QA 团队进行测试。一些QA团队自动化测试，其他人编写测试用例并手动测试。
编写：Working Effectively with Legacy Code的Michael Feathers写道，未包含在测试中的代码是遗留代码。在您体验过Big Ball of Mud之前，我认为任何开发人员都不会真正理解良好的应用程序架构和一套编写良好的单元测试的好处。让不同的人测试是一个好主意。可以查看应用程序的人越多，所有方案都会被覆盖的可能性越大，包括您不打算发生的方案。
TDD最近得到了一个糟糕的说唱。当我想到 TDD 时，我认为教条开发人员在编写实现之前会仔细编写测试。虽然这是事实，但是被忽略的是通过编写测试，（第一次或不久之后）开发人员体验消费者的方法/类。设计缺陷和缺点很明显。我认为项目的大小无关紧要。重要的是是项目的生命周期。项目生存的时间越长，开发者以外的开发人员就越有可能使用它。单元测试是应用程序期望的文档 - 各种手册。
答案 8 :(得分：1)
单元测试对于需要具有工业实力的大型项目似乎是有效的，似乎对小型项目来说可能有点过分。
移动API的单元测试确实很脆弱，但单元测试对于无API项目（如应用程序）也很有效。单元测试旨在测试项目的单元。它可以确保每个单元按预期工作。在修改 - 重构 - 代码时，这是一个真正的安全网。
就项目的规模而言，为小型项目编写单元测试确实是过度的。在这里，我将小项目定义为一个小程序，可以手动测试，但非常容易和快速，不超过几秒钟。一个小项目也可以增长，在这种情况下，手头有单元测试可能是有利的。
让开发人员和测试人员成为不同的人是有价值的，并且这两个群体之间的紧张关系有助于最终创造出一个伟大的产品。
无论开发过程是什么，单元测试并不是要取代任何其他测试阶段，而是要在开发级别进行测试，以便开发人员可以获得非常早期的反馈，而无需等待正式构建和官方测试。通过单元测试，开发团队可以提供有效的代码，下游代码，而不是无错误的代码，但代码可以由测试团队进行测试。
总而言之，我会在非常简单的情况下手动测试，或者在编写单元测试过于复杂时，我的目标是100％覆盖率。
答案 9 :(得分：1)
您的问题似乎更多地是关于自动化测试与手动测试。单元测试是一种自动化测试，但形式非常具体。
关于拥有单独的测试人员和开发人员的说法是正确的。但这并不意味着开发人员不应该进行某种形式的验证。
单元测试是开发人员快速反馈他们正在做的事情的一种方式。他们编写测试来快速运行小单元代码并验证其正确性。从某种意义上来说，你似乎并没有真正进行测试，就像编译器的语法检查没有测试一样。单元测试是一种开发技术。使用这种技术编写的代码可能比没有编写的代码质量更高，但仍需要进行质量控制。
关于自动化测试与测试部门手动测试的问题更容易回答。每当项目变得足够大以证明编写自动化测试的投资时，您应该使用自动化测试。如果你有很多小的一次性测试，你应该手动完成。
答案 10 :(得分：1)
在双方，QA和开发方面，我会断言有人应该总是手动测试你的代码。即使您使用的是TDD，您作为开发人员可能无法覆盖单元测试，也可能不考虑测试。这尤其包括可用性和美学。美学包括正确的拼写，语法和输出格式。
现实生活中的例子1：
开发人员正在创建我们在Intranet上为管理员显示的报告。有许多公式，开发人员在代码进入QA之前测试了所有这些公式。我们确认这些公式确实产生了正确的输出。我们要求开发人员几乎立即纠正的事实是这些数字在紫色背景上以粉红色显示。
现实生活中的例子2：
我在业余时间使用TDD编写代码。我想我会彻底测试它。有一天，当我有一个消息对话时，我的妻子走了过来，阅读它，然后迅速地问：“这个消息到底意味着什么？”我认为这个消息很清楚，但是当我重读它时，我意识到它正在讨论树控件中的父节点和子节点，并且可能对普通用户没有意义。我重写了这条消息。在这种情况下，这是一个可用性问题，我自己的测试没有抓住它。
答案 11 :(得分：1)
我认为可以将QA /测试人员的专业知识（定义测试/验收标准）与使用开发人员拥有的API（与GUI或HTTP /消息传递接口相对）的TDD概念相结合，以驱动被测试的申请。
拥有独立的QA员工仍然至关重要，但我们不再需要庞大的手动测试团队，而是使用FitNesse，Selenium和Twist等现代测试工具。
答案 12 :(得分：0)
只是为了澄清许多人似乎错过的东西：
TDD，意思是 “编写失败的测试，编写代码以使测试通过，重构，重复” 在编写单位测试时通常最有效和最有用。您只使用您正在处理的代码的类/函数/单元编写单元测试，使用模拟或存根来抽象出系统的其余部分。
“自动化”测试通常是指更高级别的集成/接受/功能测试 - 您可以围绕此级别的测试执行TDD，并且它通常是大量ui驱动代码的唯一选项，但是你应该知道，这种测试更脆弱，更难以编写测试，而且无法替代单元测试。
答案 13 :(得分：0)
开发人员和测试人员之间的工程紧张是一个坏消息;开发人员培养了一个“好，测试人员得到了报酬”的心态（导致懒惰）和测试人员 - 如果他们没有发现任何缺陷就觉得好像他们没有被视为工作 - 扔解决尽可能多的琐碎问题。这是对每个人时间的极大浪费。
在我简陋的经验中，最好的软件开发是测试人员也是开发人员，单元测试和代码一起编写，作为结对编程练习的一部分。这立即使两个人站在问题的同一边，共同朝着同一个目标前进，而不是让他们相互对立。
答案 14 :(得分：0)
单元测试与功能测试不同。就自动化而言，通常应该考虑当测试周期重复超过2或3次时......通常应该进行回归测试。如果项目很小或者不会经常更改或更新，那么手动测试是一种更好，成本更低的选择。在这种情况下，脚本编写和维护会使自动化成本更高。