Cucumber中Given、When、Then的顺序（Given、When、Then、When、Then）排序问题

Question

作为一名端到端自动化测试人员，我一直认为在使用Cucumber时，Given，When，Then语句（包含在Gherkin语言中）应该按照1. Given，2. When，3. Then的顺序出现。也就是说，一个测试不应该像Given, When, Then, When, Then这样出现，而应该只有Given, When, Then。

这个假设的原因是每个测试只测试应用程序的一个领域。然而，我在网上看到一些gherkin示例时发现，有时会使用以下排序：Given，When，Then，When，Then。

是否可以在编写Then之后再回到Whens，这种做法是否可接受？我知道测试仍然可以工作，只是想知道这是好还是坏的做法。

- Charlie S

---

可能是Is it acceptable to write a "Given When Then When Then" test in Gherkin?的重复问题。 - Dave Schweisguth

我不同意被接受的答案；我在这个重复的问题中添加了我的答案。 - Dave Schweisguth

你提供的链接中被接受的答案是总体上解决了BDD，而不是给定的when then排序。此外，这里被接受的答案得到了最多的投票，因此阅读此帖子的人们总体上同意被接受的答案。 - Charlie S

Answer 1

语法上可以互换；语言上不同

Gherkin 语法 目前包括六个用于描述特征步骤的关键字：

1. Given
2. When
3. Then
4. And
5. But
6. *

这些关键字是为人类消费和传达业务逻辑的便利性而存在的。然而，Gherkin 语言本身将这些关键字视为可互换的符号，因此你可以像下面这样使用良好的英语（从 Gherkin 的角度来看是语法正确的）：

But for a dollar held
Then another dollar more
Given ownership of two dollars am I.

这是完全有效的 Gherkin，但却是一个可怕的计算货币的表示。那么，如果所有单词都可以互换，为什么要有这么多单词呢？维基百科非常清楚地指出它们提供一组约定，以促进更自然风格的沟通，并且该维基甚至给出了一些单词的差异化说明。该维基还明确表示：

Cucumber 技术上并没有区分这些步骤......[种类]。然而，我们强烈建议您这样做！这些单词已经被精选出来以实现其目的，并且你应该知道这个目的以进入 BDD 思维模式。

换句话说，使用 Gherkin 术语自然地（相对而言）沟通您的特性，将复杂性深埋在步骤定义中。使用最符合语言流畅度的关键字，不要坚持一种可能不适用于所有情况的约定，因为一个良好编写的场景并不严格遵循它。

- Todd A. Jacobs

---

请问您能否在此处链接引用的维基百科页面？ - Line

Answer 2

虽然可以用那种方式编写场景，但这不是最佳实践。我曾经犯过这个错误，会在报告和维护方面引起问题。

原因之一是When声明一个动作，而Then验证该动作的结果。当 When - Then 重复时，违反了场景单个行为的规则。

对于阅读场景的人来说，也可能会变得混乱 :)

这里有一篇关于此事的文章

- Daniel Fintinariu

Answer 3

网络上有许多非常糟糕的Gherkin。此外，对于什么是好的Gherkin存在各种不同的观点。

我的观点是，When Then When Then是一种反模式。可能需要以下其中之一：

1. 您需要一个更好的Given来包括第一个When Then

或者

2. 您需要将场景分成两个部分。

通常情况下，场景中的大多数When都会成为后续场景中的Given，因为您在现有行为基础上构建新行为。

- diabolist