cucumber - BDD 场景中的断言

Question

我试图了解如何正确创建我的 BDD REST 测试场景。

根据我在网上阅读的内容，我们应该只有一对 WHEN-THEN 并且断言应该在 THEN 步骤中完成。

如果我们遇到这样的情况怎么办

鉴于用户搜索航班

用户选择座位

用户将行李添加到航班中

当用户购买航班时

然后就成功订了机票

如果我们在尝试将包添加到航班时收到 500 状态错误会发生什么。我们至少应该在所有步骤中进行基本断言吗？

标签： cucumberbddgherkincucumber-javaserenity-bdd

Answer 1

理想情况下，您只练习每个场景的行为的一个方面。一个场景包含三个部分：

Given *a context*  
When *an event occurs*  
Then *an outcome should happen*

Given 是场景发生的上下文。就场景而言，我们如何到达那里并不重要。因此，例如，如果您的用户添加了包，那么无论是通过 Gui 还是通过将数据入侵到后端都无关紧要。只要你分不出区别，没关系。你可以有多个 Givens，因为很多事情都可能适合上下文。

只有一个When是正常的，因为它是你尝试锻炼的行为的触发因素。我发现的例外是发生交互时，例如与另一个人或时间，并且您需要他们两者来正确展示行为。

Then 是行为应该产生的结果。您可以有多个 Then，因为可能有多个利益相关者或必须发生不同的事情 - 例如，当优步司机接受您的预订时，他们会成功确认他们的接受，您会收到通知，优步会了解它也。

因此，如果您想检查能够向航班添加行李的行为，那么这本身应该是一个明确的场景。如果您愿意，可以将其作为“何时”的一部分：

Given the user has selected flight B1234 LON-YYZ 22 Oct 2021 16:45
And the ticket costs $240
And extra bags cost $40
And an exit row upgrade costs $20
When they book the flight with 2 bags and an upgrade to the exit row
Then their ticket should show 2 bags and an upgrade to the exit row
And they should be charged $300.

注意我在这里提出了两个方面的行为：行李和出口行升级。我对此非常务实，但如果由于任何原因开始变得复杂，请将它们分开

重要的是你会注意到它们最终都在When中得到了锻炼。

如果您在设置Given时收到 500 错误，那并不是场景的一部分。但是，您可以选择运行更长的测试，例如冒烟测试或客户旅程。严格来说，这些不是 BDD 场景，但我发现通常值得拥有一些场景（真的，它们需要很长时间才能运行，所以请保持数量小！）

你最终会得到这样的结构：

Given the user is on the flight search page
And Flight B12345 leaves LHR for YYZ at 16:59
When they search for a flight from LHR to YYZ on 22 Oct 2021
Then Flight B12345 should show up in the results
When they add an extra bag and an exit row seat to the booking
Then the bag and exit row seat should show in the checkout
When they checkout...

etc.

散布在整个客户旅程中的“当时”正在寻找实现中期成果的地方；客户可以保存以备后用的东西，或者他们在刚刚完成的工作中获得反馈的地方。仍然是从客户的角度来看；我们没有提到 500 个错误。如果你得到一个 500 错误，它无论如何都会失败，但我们不想在代码库中乱扔这些检查，所以我们不倾向于让它们显式。

部分原因是因为这些并不是真正的测试！它们是系统如何工作的活生生的例子，恰好提供测试作为一个很好的副产品。它们帮助开发人员了解系统并轻松更改代码；预防错误，而不是捕捉错误。

话虽如此，我有时会在任何可能失败的 Given 中提出断言。作为第一步的一部分，我可能会检查该网站是否已启动。任何其他基于 Web 的问题，我都会允许作为其余旅程的一部分浮出水面。

您可能还会发现此答案对更长的客户旅程很有用。