端到端验收测试应该如何将一个大功能划分为场景？

Question

Dan North 在他的文章What's in a Story? 中提出了许多出色的观点。特别是三个：

1. 场景标题应该说明有什么不同

   您应该能够并排排列场景，并仅使用标题来描述它们的不同之处。

2. 场景应该根据给定、事件和结果来描述

   这是我在采用 BDD 的团队中看到的最强大的行为转变。只需让业务用户、分析师、测试人员和开发人员采用这种“给定/何时/然后”的词汇，他们就会发现一个模棱两可的世界消失了。

   并非所有场景都如此简单。有些最好表示为一系列事件，描述为：给定 [一些上下文] 当 [我做某事] 然后 [这发生] 当 [我做另一件事] 然后 [这个新事情发生]等等。一个示例是向导式网站，您可以在其中逐步浏览一系列屏幕以构建复杂的数据模型。只要您养成用这些术语思考的习惯，将事件和结果的顺序混合在一起是非常合适的。

3. 故事应该足够小以适应迭代

   对于如何执行此操作没有硬性规定，只要将其分解为可证明的块即可。一般来说，如果有超过五六个场景，则可以通过将类似场景组合在一起来分解一个故事。

现在假设有人试图描述一些向导式功能的端到端验收测试（就像他在上面考虑的那样）。

• 在一个人使用向导功能开始时，通过状态的不同来定义“场景”是很自然的（实际上这似乎符合他上面的第 1 点和第 2 点）——但列举每条路径肯定是不合适的通过向导（从头到尾）以完全序列化的形式产生这样的独立场景？这不仅会产生很多场景，而且每个场景都会包含很多步骤（与 Dan 的第 3 点相反）——其中很多步骤会在场景之间重复，只是为了达到它们分歧的状态！

  Scenario: Make a successful booking
    Given that I am at the booking form
    When I do A
    Then I see B
    When I do C
    Then I see D
    When I try to book
    Then I see a successful message
  
  Scenario: Attempt to book, no availability
    Given that I am at the booking form
    When I do A
    Then I see B
    When I do C
    Then I see D
    When I try to book
    Then I see no availability
  

• 另一方面，在每个决策分支的开头为每个可能的状态定义一个场景会更有效在向导功能中——When“事件”只是将功能带到下一个决策分支的单个步骤。但是，这不是将 SUT 移到堆栈中，因此我们将不再定义端到端验收测试，而是定义较低的顺序？此外，遵循和理解测试标准更不自然——这肯定会破坏 BDD 的全部意义？

  Scenario: Do first step
    Given that I am at the booking form
    When I do A
    Then I see B
  
  Scenario: Do second step
    Given that I see B
    When I do C
    Then I see D
  
  Scenario: Make a successful booking
    Given that I see D
    When I try to book
    Then I see a successful message
  
  Scenario: Attempt to book, no availability
    Given that I see D
    When I try to book
    Then I see no availability
  

  如果走这条路，在我看来，将每个决策分支划分为单独的功能更正确；然后在单个功能中只考虑每个分支的那些场景——这只是强调了我的观点，即 SUT 已向下移动。

• 也许这些端到端验收测试过于详细，整个向导（在这个阶段）应该更多地被视为一个黑盒子？但是，我不确定这如何帮助客户了解他们正在调试的内容，尤其是因为此功能的详细步骤对于整个系统的可接受性至关重要。

将此类功能划分为场景的最合适方法是什么？

Answer 1

恕我直言，每个可能状态的所有路径都覆盖得太详细了。 BDD 帮助团队协作指定并进行深思熟虑的发现。因此，您应该关注关键示例 (http://gojko.net/2014/05/05/focus-on-key-examples/)。

您的automated tests have often several purposes。基础是通过单元测试构建的，可帮助您确保正确构建产品。验收测试更上一层楼，可帮助您构建正确的产品。

Answer 2

我们大多数人在使用巫师时遇到的问题与我们表达事物的方式有关。当一个功能探索“如何”完成某件事时，它最终会变得冗长。我们应该关注的是我们为什么做事。

如果我们这样想，我们可以通过将整个向导封装为一个东西来完全否定这个问题。例如：

Feature: Fill in my tax form

Scenario: Fill in my tax form
  When I fill in my tax form
  Then my tax form should be filled in

但是，对于像这样复杂的东西，这可能是“高级”的抽象。要添加更多细节，您必须将场景分成多个部分，并找到填写每个部分的原因。然后你用原因（为什么）来写你的场景。

如果我们回到税表并假装它只包含三个部分（为简单起见）：身份、收入、支出。

现在我们可以这样写：

Feature: Tax indentification
  As someoene who is taxed
  I need to provide proper indentification
  So I pay for my tax and not someone else's

Scenario: Provide indentification
  Given I am filling in my tax form
  When I provide indentification
  Then I should be asked about my income

我们可以用类似的东西探索悲伤的道路

  When I provide insufficient identification
  Then I should be asked for more indentification

等等

当我们实现了我们应该可以写

Feature: Tax - provide income details
  ... 

Given I am filling in my tax form
And I have provided indentification
When I provide my income details
Then I should be asked about my expenses

我们可以重复探索悲伤路径的过程。请注意，Given 可以使用我们在实现身份阶段时创建的测试功能来实现。

这方面的艺术就是要找出您完成流程每个阶段的原因，以及您在完成流程的过程中所到达的各种状态的名称。另请注意，功能中的任何地方都没有提及“如何”做这些事情

最后，这几乎是您谈到的第二种方法，更强调“为什么”而不是“如何”。您可以选择抽象级别（即您将其分解为多少部分）并且您可以控制命名。语言和命名解决了您的可读性问题，特别是如果您考虑到可以从功能名称及其在文件层次结构中的位置等内容中提供的额外上下文。