Ash*_*ary 3 bdd analysis acceptance-testing
我们有一个工作流引擎,它提供了可用工作流的列表(我的意思是工作流定义,而不是实例),用户可以点击任何工作流旁边的"执行"链接,以便执行该工作流的新实例.我想以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时,一切都很清楚,但是如果你描述了一些通过(人类)用户交互启动的行为,并且从启动另一个具有复杂输出的用例(如列表)中可以明显看出的项目).知道工作流确实被执行的标准是在工作流执行列表中看到一个新项目,这是另一个故事.我有点在这里感到困惑.
我应该与数据库层进行通信并检查存储新创建的工作流实例的行 - 或者 - 我应该检查是否存在指向工作流执行列表中新实例的项目？如果第二个,那究竟是怎么回事？我应该检查一个方案中的所有列以及它自己的方案中的每一列中的正确值吗？
我可以向您推荐我最近在" 接受标准与情景"方面做过的帖子吗？我认为如果您使用类似于工作流引擎的特定用途的东西而不是通用引擎,那么该示例可能会更有启发性.例如,这是一个假宠物店,我正在尝试使用自动化工具.然后,我在宠物商店周围编写了场景,而不是试图指定通用的自动化问题.
例如,如果您的客户有时在医疗保健中,请使用您的引擎敲打一个虚假的诊断工具并编写一个场景.从一开始看起来似乎有点工作,但我发现它很快就能收回成本.
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不能替代手动测试,它只是帮助了一点.
如果您可以创建一个模糊的实际工作流引擎,它将帮助您思考您可能会错过的场景.例如,我现在不知道该工作流程如何与特定患者相关联.我发现具体的,富有想象力的例子倾向于帮助人们将其他场景可视化,而不是模糊,通用和无所不包.
另外,尝试用业务可能使用的相同语言来表达它,考虑您真正想要的业务成果.尽量不要考虑如何实现场景 - 而只是编写它.如果您真实地与您的业务人员或客户讨论他们可以想到的方案,这将会变得更加容易!
使场景运行所需的任何复杂性都会进入代码,在那里它更容易维护和重构.
作为额外的好处,通过识别具有特定需求的特定客户,您可以帮助您的客户避免将所有可能的功能放入工作流引擎中的陷阱"万一有人需要它".通过与真实的人交谈真实场景,他们将能够帮助确定哪些人需要哪些功能最多,缩小范围并帮助您提供尽可能多的价值.