在编写 BDD 功能时，我应该将之前的用户交互放入给定步骤还是何时步骤中？

我正在尝试编写多步骤业务流程的需求（通过向导）。我遇到过很多场景，用户与一个屏幕的交互会改变是否允许您在另一屏幕上选择选项。

例如（我已经模糊了实际业务，但步骤的过程和形式几乎相同）：

Feature: Personal Diagnostic Search Filter
  In order to select a Technician who offers Personal Diagnostics,
    when I've asked for a Personal Diagnostic
  As a Business Customer
  I want to limit my search to Technicians who offer Personal Diagnostics

  Background:
    Given a Business named "Big Al's Auto Supply"
      And a Customer named "Bob Test" at the "Big Al's Auto Supply" Business
      And an Account named "[email protected] /cdn-cgi/l/email-protection" owned by "Bob Test"
      And the "[email protected] /cdn-cgi/l/email-protection" Account has the "Repair Order Creator"
        permission
      And you log in as "[email protected] /cdn-cgi/l/email-protection"
      And you start scheduling a new Repair Order

  Scenario: Enter the Select Technician page when Use PD is selected
    Given you select Use PD
    When you enter the Select Technician page
    Then the PD Filter should be visible
      And the PD Filter should be selected

  Scenario: Basic Search for Technicians when PD Filter is selected
    Given a Technician named "PD Technician"
      And the Technician named "PD Technician" supports PD
      And a Technician named "Non-PD Technician"
      And the Technician named "Non-PD Technician" does not support PD
      And you select Use PD
      And you enter the Select Technician page
      And you select the PD Filter
      And you select Basic Search
    When you search for Technicians with the name "Technician"
    Then your search results should contain "PD Technician"
      And your search results should not contain "Non-PD Technician"

But on 小黄瓜维基 https://github.com/cucumber/cucumber/wiki/Given-When-Then，建议您：

避免谈论给定的用户交互

不过，他们继续破例：

登录用户（无交互建议的例外。“较早发生”的事情是可以的）。

该页面上还提到：

When 步骤的目的是描述用户执行的关键操作

如果您有大量 UI 交互，什么属于给定，什么属于 When？

在我的第一个场景中，select Use PD需要 UI 交互，因为它是创建新维修订单向导的一部分。但它是 PD Filter 可见的前提条件，当用户进入“选择技术人员”页面时触发。

第一种情况可能没那么糟糕，但第二种情况会使问题恶化。当您点击时会触发搜索Search但必须执行许多 UI 交互才能导航到该页面。其中一些相互作用也不能被掩盖，例如Use PD必须选择搜索过滤器才能出现。但这些 UI 交互并不是关键行动场景的。

作为一般规则，请尽可能多地表达该场景，就好像您正在就此进行对话一样，并尽可能多地排除不相关的信息。

例如，我希望您在上面的场景中阅读如下内容：

Given our customer Bob Test is scheduling a repair order
And we have two technicians: "Fred Technician" and "George Nontechnician"
When Bob Test decides he wants a Personal Diagnostic
And he selects a technician
Then the search results should only contain "Fred Technician"

然后采取一切必要措施使这些步骤发挥作用 - 无论是登录还是其他方式。请注意，我没有讨论“页面”，也没有采取实际步骤 - 它们对于用户来说应该是直观的。 BDD 与测试无关。这是关于提出人们将如何使用该系统的示例，以便您可以围绕这些示例进行对话并探索它们，找到例外情况和不同的场景等。

检查过滤器是否可见是没有价值的。用户不关心过滤器是否可见。他关心的是他可以使用过滤器来获得结果，所以就这样做吧。

在代码中，我通常在步骤之间传递一个“World”对象。这可以让很多小家伙摆脱困境。我没怎么用过 Gherkin，但我想它也能提供类似的功能。您可以在其中存储所有用户详细信息，您创建了哪些技术人员，以便您可以检查它不会在结果中带回“George Nontechnician”等。

使用友好的角色名称也很有用，因为人们可以想象弗雷德和乔治的样子。

去掉任何不会对场景产生影响、也不会帮助人们想象它发生的东西。您知道鲍勃有权安排订单，因为这就是他正在做的事情 - 只需向该步骤添加必要的内容即可。

“何时”是您有兴趣描述的行为。在本例中，您对筛选个人诊断的能力感兴趣，因此与行为相关的所有用户交互都应位于“何时”中，并且所有先前的交互均应位于“给定”中。我发现尝试考虑结果不同的环境很有用 - 例如，如果没有 PD 技术人员，会发生什么？这告诉我有什么区别；我们将设置一个不同的context但执行相同的操作event。上下文属于“给定”，事件属于“何时”。 （在引入“背景”之前，这曾经要简单得多）。

一般来说，如果你在看某个场景时眼神呆滞，那么你就做错了。

希望这可以帮助。