何时使用BDD以及何时进行单元测试？

Question

我的任务是为将来的Django Channels + DRF项目编写测试，不要问为什么（我们现在只有草率的文档）。因此，测试必须测试用户用例（例如可能很复杂的场景）。我对此进行了研究，发现了BDD。这是一个问题，考虑到我们的项目以后也可能具有简单的单元测试，我应该使用什么，即BDD看起来不错，但是我认为它可能会用得过多，并且可能有一种只为用户用例场景编写单元测试的方法。我可以解决的。有人有经验吗？如果您提供文章和代码示例，那就太好了。

Answer 1

方案与用例有些不同。用例通常包含几种功能。例如，在简单的洗衣用例shown here中，管家在执行洗涤时会做几件事：

• 洗每个负载
• 干燥每个负载。
• 折叠某些物品
• 熨烫一些物品

所有这些都属于“每周洗衣服”的用例。

BDD中的方案更细粒度。它描述了在特定上下文或一组上下文中发生的one能力。例如，您可能有：

Given the weekly laundry has been washed and dried
And it contains several sheets
And some underpants
When the housekeeper does the folding
Then the sheets should be folded
But the underpants should not.

您可以看到我们已经跳过了其中一些功能。此方案的重点是folding的功能，并说明行为良好的管家将如何做到。洗涤和干燥必须在单独的方案中进行介绍。

这就是用例和场景之间的区别。现在让我们看一下单元测试。

当我们编写代码时，我们不会全部都在一个大的类或函数中编写。我们将其分成小块。就像场景从用户的角度描述system的行为的示例一样，单元测试也从用户的角度描述class或其他小代码的行为。它的用户-通常是其他类！

因此，让我们想象一下我们在购车网站上。我们有几种功能：

• 认证
• 搜索汽车
• 购买汽车
• 列出汽车
• 从列表中删除汽车

其中每个将具有组成不同类别的lots。甚至搜索汽车都可能涉及前端，搜索组件，汽车数据库，持久层，Web服务器等。对于每段代码，我们都描述该代码的行为。

（BDD实际上是从这个级别开始的；给出了类的行为示例-JBehave旨在取代JUnit。但是JUnit变得更好了，我们不再需要这一点了。我仍然认为将它们视为示例而不是测试。）

通常，我的代码库中会同时包含两个场景和单元测试；一组从用户/利益相关者的角度看待整个系统，另一组更详细地描述了我的课程。

这些场景可以帮助我展示系统的行为方式以及其价值所在。单元测试可以帮助我排除不良设计并承担单独的责任。他们俩都提供了[[living documentation，这有助于保持系统的可维护性，并使新移民更容易加入。

通常，这是我编程的方式：

我对要实现的目标有一个粗略的想法
• 我与某人交谈并写下一些情况
• 如果我们不太了解我们要寻找的东西，我会得到一些有用的信息（峰值）
• 一旦我们更好地了解了我们要寻找的东西，我就会自动执行场景[[first

我采用最简单的情况并开始编写UI

当UI需要另一个类来工作时，我写了一些示例说明该代码如何工作（单元测试）

first

然后我编写代码（或重构它，因为尖峰很乱）

当该代码需要另一个类工作时，我写一些例子

如果我在单元测试中的任何时候都没有需要的代码，则使用模拟。

通常，我们将场景和单元测试放在不同的位置。

您可以看到一些有关如何完成此here的示例。这是一款俄罗斯方块游戏，具有可通过UI自动化整个游戏的场景，以及用于描述特定部件（例如心跳形状）行为的较低级单元测试。

话虽如此-如果您的代码库非常简单，则可能只需要解决方案或单元测试就可以了；您可能不需要两者。但是，如果它变得越来越复杂，请考虑重构并添加所需的内容。只要很容易更改，就可以务实。