在 BDD 测试中混合何时和然后

Question

在进行行为驱动开发时，是否有一种标准方法来决定如何在简单测试和过多测试之间进行权衡？

我正在为一个新项目实施 BDD，最近我通读了 John Smart 的 BDD In Action 一书。本书建议不要混合使用When 和Then 步骤。这似乎会导致更多的测试，从简单的角度来看这可能是可取的，但可能会增加运行测试所需的时间。

我正在考虑如下场景：

Given that a user exists with the following details:
  first name | email
  Bill       | bill@example.com
When I submit the forgot password form
Then bill@example.com should receive a forgot password email
And the email body should contain Bill
When I visit the password reset link
And I use ;v'H~N0et,)S}*VX@fQH9=sm@i1jw|'f as my new password
Then I should be logged in
When I log out
And I log in with password ;v'H~N0et,)S}*VX@fQH9=sm@i1jw|'f
Then I should be logged in

这显然混合了多个 When 和 Then 步骤，但替代方案有 3 个场景：

Given that a user exists with the following details:
  first name | email
  Bill       | bill@example.com
When I submit the forgot password form
Then bill@example.com should receive a forgot password email
And the email body should contain Bill

Given that I have a password reset email
When I visit the password reset link
And I use ;v'H~N0et,)S}*VX@fQH9=sm@i1jw|'f as my new password
Then I should be logged in

Given that I have a password reset email
When I visit the password reset link
And I use ;v'H~N0et,)S}*VX@fQH9=sm@i1jw|'f as my new password
When I log out
And I log in with password ;v'H~N0et,)S}*VX@fQH9=sm@i1jw|'f
Then I should be logged in

有没有推荐的方法来实现这样的测试？在这种场景中混合步骤可以吗？

也许解决方案是确保场景之间的重置过程不会显着影响测试，但如果我们需要在每次测试之间重置数据库，这可能会很困难。

Answer 1

BDD 纯粹主义者会告诉你让它们分开场景。这确实意味着更多的测试，但这里的优势是每个测试只有一个失败的原因。

我的 BDD 实用主义者会告诉你，偶尔混合使用 When 和 Then 步骤是可以的。只是不要养成这样做的习惯。

如果您正在测试的功能经常更改，我会将其拆分为多个场景，每个场景中只有一个 Then。如果密码重置功能不经常更改，我可能会选择一碗When 和Then 意大利面条，然后收工。如果测试变得“不稳定”并且经常失败，我会考虑将其拆分为不同的场景。

Answer 2

我倾向于按能力区分场景。你有几个在那里进行：

• 请求和发送“重置密码”链接的能力
• 重置密码的功能
• 使用新密码登录的能力。

确实，对于您在此处获得的场景，将它们组合起来可能更实用。我有时会为琐碎的情况这样做，特别是如果有一个事情出错，然后是同样的事情做对了。例如，我可能会这样做：

Given I'm registered with the password `abcd`
When I try to log in with the password `abcf`
Then it should tell me my credentials are incorrect
When I log in with the password `abcd`
Then it should take me to my homepage.

是的，严格来说，这应该是两个不同的场景。不过它们很​​容易分开，所以我可以这样做。

但是，当您开始遇到多种功能时，通常表明您拥有的场景数量可能即将爆炸式增长。您可以通过询问“是否有任何其他上下文对于同一事件会产生不同的结果？”来找到其他场景？

例如，您有一个密码重置链接。

• 如果电子邮件地址被退回怎么办？
• 如果链接超过 14 天怎么办？
• 如果提供的密码与之前的密码相同怎么办？
• 如果请求中提供的电子邮件地址未在您的系统中注册怎么办？

如果你结合这种情况，突然之间真的很难看出发生了什么，以及正在执行哪些行为。

在这种情况下，我们使用的是众所周知的行为。对我们来说很明显，它提交了允许某人登录的新密码。我们可以看出，我们不只是通过点击链接自动登录。

（值得注意的是，尽管大多数网站会让您使用新密码重新登录，而不是在提交密码后自动登录，所以已经有一些有趣的行为可以讨论，如果我们有多种场景。）

当我们开始包含我在此处列出的其他一些场景时，更难看到发生了什么。

当它是一个我们不熟悉的域时，它变得更加困难；当围绕这些场景的对话被用于协作、消除误解以及传递知识和专业知识时。

所以我可以从一个场景开始，实用主义；但请注意，它可能需要很快重构为多个。这不仅是为了以防您需要了解场景何时失败，而且是为了让您在阅读它们时能够了解系统的行为。

BDD 更多的是关于动态文档而不是测试。真正出色的 BDD 往往会帮助人们更改代码而不引起错误，甚至比捕捉错误更重要。单一用途的场景可以帮助解决这个问题。

This answer I gave on automating whole user journeys（当你故意有多个时间和时间时）也可能会给你更多的洞察力。