我终于忍受了测试。目前，我试图了解不同方法和技术之间的差异。
总有一件事让我觉得，与BDD风格测试相比，单元测试通常被认为是开发人员（以及唯一的开发人员）测试代码的廉价方式。
如果我做对了，单元测试每个都覆盖一个函数或方法，尽可能隔离测试它以确保内部连接正确，而BDD测试验证正确的事情正在发生。在TL中; DR版本可能是这样的：＆＃34;当我单击此按钮时，事件处理程序是否被调用？＆＃34; vs＆＃34;当我点击此按钮时，产品是否已放入购物车？＆＃34;。
现在，为什么单元测试被认为比其他测试方法更便宜？
在我看来，单元测试甚至可能更令人生畏，因为它不足以验证发生了正确的事情（是什么），但是通过单元测试你必须实际验证 如何发生这种情况。
答案 0 :(得分：3)
单元测试“更便宜”，因为执行它们所需的资源少于其他测试方法。单元测试很容易做到，并且允许对函数进行抽象评估以获得正确的功能 - 它们不会评估它们与整个系统的交互方式。
因此，单元测试不会：
由于单元测试的性质，可以提高生产率，因为浪费了更少的时间来执行集成或理解系统流程。
良好的单元测试需要以下内容：
这些规范导致测试快速，完成工作，无需人工干预，即使在检测到故障后也能继续进行。由于这些原因，单元测试“成本”低于其他类型的测试。
答案 1 :(得分：2)
单位测试在几个方面很便宜：
首先，单元测试的原因是：给出一些易于理解的输入和预期输出，当测试中的代码运行时，那么一些断言应该成立。
接下来开发代码的推理：输入，转换和输出。
当您编写测试代码和正在开发的代码而不打破注意力时，您将获得代码和可重复的测试，而无需重新引入自己或其他人来解决问题。从测试角度出发的推理可以更好地告诉您编写测试代码。
所以，它很便宜，因为你不需要太多额外的推理，而这种推理补充了编写测试代码的推理。
理想情况下，他们只依赖于一个模块。 （我不是一个理想主义者。如果您需要多个模块来完成工作，那么就这样吧。）这使得单元测试运行得更快。由于除了被测试模块之外的模块发生了变化，因此单元测试不太可能发生变化。
因此，它很便宜，因为您几乎没有设置来运行测试，并且它们只需要很少的时间来执行。
瀑布模型的问题在于它没有考虑反馈。敏捷的目的不是阻止反馈循环 - 它认为它们是不可避免的。没有比在几秒钟内运行的测试更快的反馈，并且只要您编写代码就可以使用。
因此，它很便宜，因为在获得有关代码正确性的反馈之前，您几乎没有时间投入。
早在90年代后期，每个人都害怕更改代码，因为他们无法确定更改的副作用，而且更改需要大量的测试工作。通过单元测试的快速反馈，开发人员可以重构，更不用担心意外的副作用和对更广泛系统的影响。
因此它很便宜，因为您可以对小代码调整更有信心，并且许多小代码调整可以构成更好的代码。
自动化单元测试为开发人员提供即时反馈。持续集成是一种方法，包括自动执行单元测试和其他自动化测试。这为整个团队提供了整个项目的反馈。它还增加了构建的可信度，因为它们与特定开发人员的工作站隔离开来。
所以它很便宜，因为它可以促进某种程度的“完全”＃34;在每次代码更改后进行测试，这比等待很长时间进行大量手动测试要好。比测试人员要便宜得多。
此外，你说单元测试检查＆＃34;如何＆＃34;而不是＆＃34;什么＆＃34;。单元测试应该集中在＆＃34;什么。＆＃34;单元测试应该测试类或模块的公共接口。一些单元测试利用模拟来减少依赖项的数量。在Percival的书＆＃34;使用Python进行测试驱动开发，＆＃34;他解释了如何使用模拟将测试与接口相比更接近实现。在从实现中解耦（没有模拟，但可能需要额外的模块）和从其他模块隔离（使用模拟与其他模块隔离，可能将测试更多地与实现相关联）之间存在权衡。在此过程中还有许多其他权衡决策，做出正确的决定并非易事。
此外，Percival支持双循环TDD或编写功能测试，然后进行单元测试，然后是测试中的代码。据我所知，行为驱动开发（BDD）利用了一些特定于域的代码编写的验收测试。我将这些解释为比Percival所支持的功能测试更抽象的测试。我不认为这些BDD测试太重了。坦率地说，我没有任何相关经验。
我鼓励您在测试金字塔的多个级别进行测试。如果某个特定的测试非常适合其目的，并且适合各个级别，那么您不必将其单元化或行为化。只是让它最好地实现其目的。
关于指标的说法也是如此，它也适用于自动化单元测试：自动化测试很难，而且自动化测试错误会导致维护难题或虚假的安全感。我们还是要做测试。