Question

在行为驱动开发编写自动化功能测试的风格中，通常理解 Givens 应该是系统必须处于的先决条件，以便开始测试，当应该执行用户操作时，然后应该断言观察到的是否与预期匹配并失败或相应地通过测试。

我的团队已经开始在Givens和Whens开始执行断言，这让我想知道这是不是一种正确的做法。

例如 -

Given a user with xyz privileges is logged in
When I click on the abc tab
Then records should be displayed

此测试中的 Given 是否应该断言登录用户确实具有 xyz 权限或假设用户具有所需权限并且只是执行登录

何时断言该选项卡在单击？

之前是否可见

Answer 1

如果“登录”是一个有趣的行为*并且您需要举例来说明它**那么它应该是“何时”，其中发生的上下文是“给定”，以及结果是“然后”。

您需要通过示例说明任何行为。

但是，有时在Given中进行断言可能很有用，只是为了检查上下文是否确实正确设置。有时，当人们开始采用BDD时，环境可能有点不稳定，并且知道您的方案是否找到导致其失败的错误，或者在此过程中更早的某些内容，这很方便。因此，你可能会在那里找到断言。

然而，

Given并不关心系统如何进入该状态。如果它有断言，那应该只是检查是。

我看到的另一种形式是检查系统是否处于上下文的正确状态，如果不是则采取纠正措施。

请注意，这些主要是临时模式。当团队采用BDD并使其管道和自动化部署成型时，它们可以提供帮助。

检查“When”结果的断言是结果的一部分，所以“Then”的一部分。我无法想象你需要检查“何时”的结果，而不是结果。如果你有一个，请给我一个例子。

We discourage using clicking and UI details in scenarios.找出你想要实现的目标，并做到这一点。隐藏封面下的点击。

大多数情况下，自动化方案实际上并不存在捕获错误;它们是生活文档，可以帮助人们思考他们想要实现的目标以及系统已经做了什么，从而鼓励良好的设计并首先防止错误。

我会说“导航到ABC标签”，然后就这样做;如果没有相关的例外，你会得到一个相关的例外情况，并且不会像阅读情景的人那样经常发生。

*它正在登录。可能不是。
**它正在登录。你可能没有。

Answer 2

Givens和Whens中的断言通常是步骤定义不成熟的指标。所以我可能会把它放在我正在努力的一个步骤中，但我不会在那里保留很长时间。

我实施你的步骤

Given a user with xyz privileges is logged in

就像

一样

'Given a user with xyz privileges is logged in' do
  user = create_user(privileges: xyz)
  login_as user: user
end

我希望create_user方法可以很快得到信任，并且不需要断言。 login_as方法也是如此。（如果这样的方法不能正常工作，你会发现很多场景都会被打破）

请注意这段代码如何清楚地表明有两件事正在进行并提供/使用api，您可以期待许多其他stepdef使用。你可能想要保留的任何断言如何真正属于辅助方法而不是步骤def。

Answer 3

根据我的经验，没有严格的规则我觉得定义那里没有断言很方便，所以很清楚实际测试的是什么，测试本身会运行得更快。

如果你的abc标签没有显示，它就不应该被点击，然后在确定要点击的对象或执行下一步时（取决于你使用的工具和方法），测试将失败

但是，您应该确保测试的实际实现不会作弊并使用能够触发点击的内部构件，即使实际组件不是。

关于Given还有另外一点，通常建议为测试设置环境。这意味着您确保在您的系统中有一个用户并且该用户已经登录。在您设置它时没有任何意义，但是如果发生任何故障，您应该快速地知道错误。< / p>

Answer 4

通常我会在自动化代码中的Given或When步骤中使用断言。

但是，我在我的代码中使用这样的登录步骤 - 如果使用正确 - 可以将步骤转换为一个上下文而不是断言本身。

例如：

此用户是否已登录？

在您给出的示例中，我们知道我们需要登录特定用户才能使此方案正常工作，但我们不知道是否有其他用户登录（其他方案可能已在其之前运行）。如果您使用此步骤作为检查以确保正确的用户已登录（如我的示例中所示），则它是上下文的一部分，它将加快自动化的运行时间，因为您不必在每个方案之前登录并注销。