我们有一个工作流引擎，它显示了可用工作流的列表(我的意思是工作流定义，而不是实例)，用户可以单击任何工作流旁边的“执行”链接来执行该工作流的新实例。我想以 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 时，一切都很清楚，但是如果你描述的是通过(人类)用户交互启动的一些行为，并且其结果从启动另一个具有复杂输出的用例(如列表)中显而易见项)。知道工作流确实被执行的标准是在工作流执行列表中看到一个新项目，这本身就是另一个故事。我在这里感到有点困惑。
我应该与数据库层交谈并检查存储新创建的工作流实例的行 - 还是应该检查指向工作流执行列表中的新实例的项目的存在？如果是第二个，那么具体如何？我应该在一个场景中检查所有具有正确值的列还是在它自己的场景中检查每一列？
最佳答案
我可以向您推荐我最近在 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.
这是您正在寻找的好处 - 用户获取一些信息，而不是存储在数据库中的信息。尽可能地，一个场景应该插入最终值(value)!所以也许它甚至应该说:
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)。
关于bdd - BDD 故事的验收标准(和其他条件)，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/7704172/