【问题标题】:Is it ok to have multiple groups of Given/When/Then in a single gherkin scenario在一个小黄瓜场景中是否可以有多组 Given/When/Then
【发布时间】:2021-12-15 06:42:35
【问题描述】:

我正在 Gherkin 中编写验收测试,我想测试基于初始操作的 Web 应用程序 UI 中的多项更改。这是一个例子:

        Scenario: Cancel editing a new text asset
            Given the user "test_user@fakedomain.com" is logged in
            When the user navigates to "/build/"
            And the user clicks the "Sandbox" link
            And the user inputs "Test story for canceling editing of a new text asset" for the "title" field
            And the user inputs "Test User" for the "byline" field 
            And the user inputs "My summary, so exciting!" for the "summary" textarea
            And the user clicks on "Untitled Section" in the section list
            And the user clicks the "Text" icon in the "center" container 
            And the user inputs the following text in the rich text editor:
                    """
                    Test text for asset. This is cool. 
                    """
            And the user clicks the "cancel" button
            Then the following text is not present: 
                    """
                    Test text for asset. This is cool. 
                    """
            And the "Image" icon is present
            And the "Text" icon is present
            When the user refreshes the browser 
            And the user clicks on "Untitled Section" in the section list
            Then the following text is not present:
                    """
                    Test text for asset. This is cool. 
                    """
            When the user opens the asset drawer
            Then the following text is not present:
                    """
                    Test text for asset. This is cool.
                    """

请注意,有多组 When/Then 步骤,用于测试初始操作的响应。虽然大多数步骤的实现都忽略了前缀关键字,而且我很确定我可以让这个测试运行,但有没有更好的方法来测试不同的结果?使用相同的设置但不同的“Then”语句编写多个场景是否更好?

【问题讨论】:

标签: testing bdd gherkin


【解决方案1】:

请记住,您一次只能测试一种行为/功能。 经验法则是您应该只使用一个When step

Given some state before action
  And some other state before action
  ...
When  only one action
Then  assert correct output
  And assert correct output
  ...

你看-只有一行When,在When下没有任何Ands。如果您改用许多 When 步骤,您将创建测试脚本,而不是规范。您的测试将难以理解,并且您会注意到当底层实现发生变化时您会添加越来越多的步骤。

您还需要隐藏底层逻辑,因为您不想每次更改不相关的内容时都更改它。示例:

然后用户输入“我的总结,太令人兴奋了!”对于“总结” 文本区域

如果您将汇总字段从文本区域更改为输入类型怎么办?您必须更改场景(维护噩梦)或让您的场景躺着(比没有场景更糟糕)。你应该改写:

When the user describes it as "so exciting!"

但是,整个场景的结构仍然很糟糕。问自己一个问题:我要检查什么?如果我是一个想了解该功能的业务逻辑的人,我希望看到如下内容:

Scenario: Cancel editing a new text asset
  Given I edit the Sandbox details with some data
  When  I cancel editing
  Then  Sandox details should be empty

就是这样!

如何实现呢?将所有不相关的逻辑移得更深,使用PageObject pattern 等。阅读Specification By Example

【讨论】:

  • 感谢您的帮助。我听到您所说的使规范反映功能的核心业务逻辑,从而使它们更具前瞻性。那么使用功能/场景来测试围绕功能的特定 UI 实现是否不合适?如果是这样,什么会更合适?我知道在我的示例中,功能与特定 UI 组件之间的边界存在一些歧义。
  • 1.对于 UI 测试,仅当(由于使用的工具、框架等)这是最快的方法时才使用 gherkin。 2.如果你用gherkin和别人沟通,关注用户目标,而不是UI,用PageObjects来包装底层逻辑。对于前者,使用最快的工具——大多数时候商务人士不会担心文本区域和输入字段之间的差异。例如,我只使用 PageObjects + Javascript 单元测试来测试 UI 逻辑,因为在我们的例子中这是最快的方法。
  • Gherkin 旨在涵盖您的业务规则,而不是您的代码。 BDD 是关于应用程序设计,而不是应用程序测试。如果您有需要测试的功能元素,请使用功能测试框架或一套全面的单元测试。
  • @GregGauthier 请原谅我对您的评论的迟到回复。我同意你的看法。如果您阅读了我的第一点,我也不鼓励使用 Gherkin 语言作为 UI 测试框架。我说过您应该考虑在所有其他选项都更差/更慢时使用它,而现在可能永远不会出现这种情况。您可以阅读我的michaelszymczak.com/article/testing-business-rules.html 系列,了解我更喜欢仅将 Gherkin 用于指定业务规则。我们在同一页面上。
【解决方案2】:

与上一个答案相比,对于如何使用定义步骤没有严格的规定。 https://cucumber.io/docs/gherkin/reference/ 上的 Cucumber 官方文档 建议 使用 only one When,因为只有一个行为被列在一个接受标准中。这只是一个建议,而不是规则。 Cucumber 文档主要关注验收标准规范,而不是测试自动化。 因此,在自动化测试方面,绝对有可能遵循它最适合您的要求。 我建议通过合并不同的步骤来使用更少的“和”关键字。我推荐以下几点(这是建议,但不是规则:)):

  1. 在场景的一个流程中仅使用一个 Given、When 和 Then 关键字,如果您需要在适当的事件中指定额外的步骤,请使用“And”关键字
  2. 如果您使用过多的“And”关键字,请尝试合并多个此类步骤

实际上,我们不能在测试自动化中只使用一个When,因为:

  1. 自动化测试数量增加
  2. 自动化的总执行时间增加了
  3. 如果我们只使用一个When,我们可能会在多个场景中执行大量冗余操作。假设您需要执行 5 个步骤作为测试 10 个不同操作的初始条件。在这里,当您只使用一个“When”时,您将执行这 5 个步骤 10 次 - 这会消耗太多时间,并导致测试不稳定,并导致应用程序负载增加
  4. 由于测试次数的增加,我们需要花更多的时间来分析结果,更多的时间来维护

我还建议根据需求测试行为。如果您的要求是在“测试区域”而不是“输入区域”中验证某些内容,那么您的步骤应该表明这一点。请记住,如果需求发生变化,开发就会发生代码变化,因此测试自动化代码也会发生变化。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2023-03-26
    • 1970-01-01
    • 2019-12-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多