3

我们有一个工作流引擎，它提供可用工作流的列表（我的意思是工作流定义，而不是实例），用户可以单击任何工作流旁边的“执行”链接，以执行该工作流的新实例。我想以 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
"""

（第 1 列：项目编号，第 2 列：工作流名称，第 3 列：状态）

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

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

4

1 回答 1

5

我可以向您推荐我最近在接受标准与场景方面所做的一篇文章吗？我认为如果您使用类似于工作流引擎的特定用途的东西，而不是通用的，这个例子可能会更有启发性。例如，这是我用来试用自动化工具的假宠物店。然后我围绕宠物店编写了场景，而不是尝试指定通用的自动化问题。

例如，如果您的客户有时从事医疗保健，请敲出一个使用您的引擎的假诊断工具并围绕它编写一个场景。一开始可能看起来有点工作，但我发现它很快就会收回成本。

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 不能替代手动测试，它只是有点帮助。

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

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

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

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

于 2011-10-13T14:45:40.517 回答