bdd - BDD 故事的验收标准(和其他事项)

Question

我们有一个工作流引擎，它会显示可用工作流列表(我指的是工作流定义，而不是实例)，用户可以单击任何工作流旁边的“执行”链接来执行该工作流的新实例。我想以 BDD 方式完成这个“执行工作流”故事(功能？)。

    Story: execute a workflow
    Scenario: execute a workflow by clicking on execute link in workflow list and nothing goes wrong
    Given I am a user with sufficient rights
    And I have added a workflow called "wf"
    When I click on the execute link next to "wf" in the workflows list
    When I view the list of workflow executions
    Then the output is:
"""
    1 | wf1 | not started
"""

(第一列:项目编号，第二列:工作流名称，第三列:状态)

我觉得这更像是一团糟，而不是一个很好的 DBB 场景，我特别关心验收标准。我不清楚我应该如何处理粗粒度和用户耦合的事情，比如“执行工作流”。我的意思是当它是你正在做的 API 时，一切都很清楚，但是如果你正在描述一些通过(人类)用户交互启动的行为并且其结果从启动另一个具有复杂输出的用例(如列表)中显而易见项)。知道工作流确实执行的标准是在工作流执行列表中看到一个新项目，这本身就是另一回事。我在这里有点困惑。

我应该与数据库层对话并检查存储新创建的工作流实例的行 - 或者 - 我应该检查工作流执行列表中是否存在指向新实例的项目？如果是第二个，那么具体如何呢？我应该在一个场景中检查所有具有正确值的列还是在它自己的场景中检查每个列？

Answer 1

我可以向您推荐我最近在 Acceptance Criteria vs. Scenarios 上发表的一篇文章吗？ ？我认为如果您使用类似于工作流引擎的特定用途的东西而不是通用的东西，那么这个例子可能会更有启发性。例如，here's a fake pet shop我正在使用它来试用自动化工具。然后我written scenarios around the pet shop ，而不是试图指定通用的自动化问题。

例如，如果您的客户有时从事医疗保健工作，则可以构建一个使用您的引擎的虚假诊断工具，并围绕该工具编写一个场景。开始时似乎需要做一些工作，但我发现它很快就能收回成本。

Story: A doctor diagnoses black death

Scenario: The doctor starts the diagnosis

Given I am doctor with rights to use the system
And I've added a workflow called "diagnosis"
When I choose the "diagnosis" workflow
Then it should tell me that it's not started.

这就是您正在寻找的好处 - 用户获取一些信息，而不是将某些信息存储在数据库中。尽量一个场景去推最终值!所以也许它甚至应该说这样的话:

Story: A doctor diagnoses Black Death

Scenario: The doctor starts the diagnosis

Given I am doctor with rights to use the system
And I want to diagnose a patient
When I choose "Diagnosis"
Then the system should prompt me to start diagnosing.
Given that all the symptoms match Black Death
When I perform the diagnosis
Then I should be able to diagnose the patient with Black Death.

任何使这变得简单和美观所需的更小的步骤实际上都是可用性问题。不要使用 BDD 框架来描述可用性问题(尽管它们可以逐步解决这些问题，从而为您提供回归测试)。相反，请手动尝试。 BDD 不能替代手动测试，它只是提供一点帮助。

如果您可以创建一个模糊现实的工作流引擎用法，它会帮助您想到您可能会错过的场景。例如，我现在不知道这个工作流程如何与特定患者相关联。我发现具体的、富有想象力的例子往往比模糊、通用和无所不包的东西更能帮助人们想象其他场景。

此外，请尝试使用业务可能使用的相同语言来表达它，并考虑您真正想要的业务成果。尽量不要考虑如何实现场景 - 相反，只需编写它即可。如果您真的去与您的业务人员或客户讨论他们可以想到的场景，这将容易得多!

让场景运行所需的任何复杂性都会进入代码，这样更容易维护和重构。

作为一个额外的好处，通过识别具有特定需求的特定客户，您可以帮助您的客户避免将每个可能的功能都放入工作流引擎中以“以备不时之需”的陷阱。通过与真实的人讨论真实场景，他们将能够帮助确定谁最需要哪些功能，缩小范围并帮助您提供尽可能多的值(value)。