这个假设的原因是每个测试只测试应用程序的一个领域。然而,我在网上看到一些gherkin示例时发现,有时会使用以下排序:Given,When,Then,When,Then。
是否可以在编写Then之后再回到Whens,这种做法是否可接受?我知道测试仍然可以工作,只是想知道这是好还是坏的做法。
Gherkin 语法 目前包括六个用于描述特征步骤的关键字:
Given
When
Then
And
But
*
这些关键字是为人类消费和传达业务逻辑的便利性而存在的。然而,Gherkin 语言本身将这些关键字视为可互换的符号,因此你可以像下面这样使用良好的英语(从 Gherkin 的角度来看是语法正确的):
But for a dollar held
Then another dollar more
Given ownership of two dollars am I.
这是完全有效的 Gherkin,但却是一个可怕的计算货币的表示。那么,如果所有单词都可以互换,为什么要有这么多单词呢?维基百科非常清楚地指出它们提供一组约定,以促进更自然风格的沟通,并且该维基甚至给出了一些单词的差异化说明。该维基还明确表示:
Cucumber 技术上并没有区分这些步骤......[种类]。然而,我们强烈建议您这样做!这些单词已经被精选出来以实现其目的,并且你应该知道这个目的以进入 BDD 思维模式。
换句话说,使用 Gherkin 术语自然地(相对而言)沟通您的特性,将复杂性深埋在步骤定义中。使用最符合语言流畅度的关键字,不要坚持一种可能不适用于所有情况的约定,因为一个良好编写的场景并不严格遵循它。
虽然可以用那种方式编写场景,但这不是最佳实践。我曾经犯过这个错误,会在报告和维护方面引起问题。
原因之一是When
声明一个动作,而Then
验证该动作的结果。当 When - Then 重复时,违反了场景单个行为的规则。
对于阅读场景的人来说,也可能会变得混乱 :)
这里有一篇关于此事的文章
网络上有许多非常糟糕的Gherkin。此外,对于什么是好的Gherkin存在各种不同的观点。
我的观点是,When Then When Then是一种反模式。可能需要以下其中之一:
或者
通常情况下,场景中的大多数When都会成为后续场景中的Given,因为您在现有行为基础上构建新行为。