行为驱动测试与单元测试重叠是否可以？答案

【问题标题】：Is it OK to have Behavior Driven Tests overlap with Unit Tests?行为驱动测试与单元测试重叠是否可以？
【发布时间】：2020-08-16 17:40:45
【问题描述】：

目前，我正在为将 BDD 与 TDD 混合在一起的概念而苦苦挣扎，尤其是在测试重叠时。

假设我有一个单元测试来验证当我将两个数字相加时它会返回总和。下一个单元测试表明，当我将两个数字相乘时，它会返回乘积。

客户的要求是他们必须能够同时乘法和加法。编写此行为测试有效地重叠了两个单元测试，已经测试了这些功能。像这样的行为测试很有可能会发现需要能够同时进行加法和乘法运算的问题......所以我觉得它很有用。

但我觉得有些人可能会认为这个测试是多余的，因为就像我说的那样，它在技术上是重叠的单元测试......这是正常的并且可以接受吗？

另外，使用模拟而不是真实系统的行为测试呢？网上看好像没有什么苛刻的要求，但我觉得如果场景足够具体，用 mock 就完全没问题了？

【问题讨论】：

【解决方案1】：

同时使用 BDD 和 TDD 时，会有一些重叠。然而，两者都用于两种不同的目的。 BDD 不应仅用作测试框架。 BDD主要用于跨职能协作。在 BDD 中，团队协作并派生以自然语言编写的真实世界示例。只有这样，这种共同的理解才会被采纳和自动化。

BDD 通常涵盖的场景是端到端流程。作为 BDD 的一部分，您的测试中的会话是共享的。例如，您可能有以下场景：

假设用户登录成功
当用户申请工作时
然后应该返回一个工作申请号

在上述场景中，在 Given 步骤中，底层脚本可以调用登录 API 来获取令牌并将其传递给后续步骤。换句话说，状态是共享的。同样在上述场景中，可以调用数据库或网站或 REST 端点或 MQ 或任何端点/接口来发送和验证结果。

而在 TDD 中，会话不是共享的，所有外部端点/数据库都是模拟的。仅测试代码的功能。当同时使用 BDD 和 TDD 时，你肯定会有一些重叠。在上面的示例中，您可以通过模拟验证登录的 REST API 来创建一个仅测试登录功能的 TDD。

正如我上面提到的，您不应将 BDD 视为测试框架，而应将其视为协作工具，并且自动化会带来很大的好处。

这是我整理的一篇文章，解释了 TDD 和 BDD 之间的区别 https://blog.nocodebdd.com/bdd-vs-tdd/

【讨论】：