我们有一个工作流引擎，它提供了一个可用工作流列表（我的意思是工作流定义，而不是实例），用户可以点击任何工作流旁边的“执行”链接，以便执行该工作流的新实例。我想以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时，一切都很清楚，但是如果你描述了一些通过（人类）用户交互启动的行为，并且从启动另一个具有复杂输出的用例（如列表）中可以看出结果的项目）。知道工作流确实被执行的标准是在工作流执行列表中看到一个新项目，这是另一个故事。我有点觉得很困惑。
我是否应该与数据库层对话并检查存储新创建的工作流实例的行 - 或者 - 我应该检查是否存在指向工作流程执行列表中新实例的项目？如果第二个，那究竟是怎么回事？我应该在一个场景中检查所有具有正确值的列，还是在它自己的场景中检查每一列？
答案 0 :(得分：5)
我可以向您推荐我最近在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不能替代手动测试，它只是有点帮助。
如果您可以创建一个模糊的现实工作流引擎，它将帮助您思考您可能会错过的场景。例如，我现在不知道该工作流程如何与特定患者相关联。我发现具体的，富有想象力的例子往往会帮助人们想象其他场景，而不是模糊，通用和无所不包。
此外，尝试使用业务可能使用的相同语言对其进行措辞，考虑您真正想要的业务成果。尽量不要考虑如何实现场景 - 而只是编写它。如果你真的去和你的商业人士或客户讨论他们能想到的情景，那么会更容易 。
使场景运行所需的任何复杂性都会进入代码，在那里它更容易维护和重构。
作为额外的好处，通过识别具有特定需求的特定客户，您可以帮助您的客户避免将所有可能的功能放入工作流引擎中“以防万一有需要”。通过与真实的人交谈真实场景，他们将能够帮助确定最需要哪些功能，减少范围并帮助您提供尽可能多的价值。