BDD 故事的接受标准（和其他事项）
我们有一个工作流引擎，它显示可用工作流的列表（我的意思是工作流定义，而不是实例），用户可以单击任何工作流旁边的“执行”链接来执行该工作流的新实例。我想以 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 时，一切都很清楚，但是如果您正在描述通过（人类）用户交互启动的某些行为，并且其结果通过启动另一个具有复杂输出的用例（例如列表）而显而易见，该怎么办？的项目）。知道工作流确实执行的标准是在工作流执行列表中看到一个新项目，这本身就是另一个故事了。我在这里感到有点困惑。
我应该与数据库层对话并检查存储新创建的工作流实例的行，还是应该检查工作流执行列表中是否存在指向新实例的项目？如果是第二个，那么具体如何？我应该检查一个场景中具有正确值的所有列还是其自己场景中的每一列？
We have a workflow engine that presents a list of available workflows (I mean workflow definitions, not instances) and user can click on the "Execute" link next to any workflow to ,well, execute a new instance of that workflow. I want to do this "execute a workflow" story(feature?) in the BDD way.
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
"""
(1st column: item#, 2nd: workflow name, 3rd: state)
I kinda feel this is more like a mess than a nice cut DBB scenario, I'm specially concerned with the acceptance criteria. My mind is not clear about how exactly I should approach something coarse-grained and user-coupled like "executing a workflow". I mean when it is API you are doing, everything is clear but what if you are describing some behavior which is initiated through (human)user interaction and the result of which is evident from initiating another use-case with complex output (like a list of items). The criteria for knowing that the workflow is indeed executed is to see a new item in the list of workflow executions, which is another story for itself. I kinda feel confused here.
Should I talk to database layer and check for the row that stores the newly created workflow instance -or- should I check for the presence of the item that points to the new instance in the list of workflow executions? If the second, then how exactly? should I check for all columns with correct values in one scenario or each column in it's own scenario?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我可以向您推荐我最近发表的一篇关于接受标准与场景的文章？我认为，如果您使用类似于工作流引擎的特定用途的东西，而不是通用的东西，那么这个示例可能更具启发性。例如，这是一家假宠物店，我正在用它来尝试自动化工具。然后，我编写了有关宠物店的场景，而不是而不是试图指定通用的自动化问题。
例如，如果您的客户有时在医疗保健领域，请使用您的引擎构建一个虚假的诊断工具，并围绕它编写一个场景。一开始似乎需要做一些工作，但我发现它很快就能收回成本。
这就是您正在寻找的好处 - 用户获取一些信息，而不是将某些信息存储在数据库中。场景应该尽可能推动最终价值！因此，也许它甚至应该这样说：
使这变得简单和美观所需的任何较小的步骤都是真正的可用性问题。不要使用 BDD 框架来描述可用性问题（尽管它们可以逐步解决它们，从而为您提供回归测试）。相反，请手动尝试。 BDD 并不能替代手动测试，它只是提供一点帮助。
如果您可以创建工作流引擎的模糊现实用途，它将帮助您想到可能会错过的场景。例如，我现在不知道如何将此工作流程与特定患者相关联。我发现具体的、富有想象力的例子更能帮助人们想象其他场景，而不是模糊的、笼统的和包罗万象的东西。
此外，尝试用业务可能使用的相同语言来表述它，并考虑您真正想要的业务成果。尽量不要考虑如何实现该场景 - 相反，只需编写它即可。如果您真的去与您的业务人员或客户讨论他们可以想到的场景，这将容易得多！
使场景运行所需的任何复杂性都会进入代码，这样更容易维护和重构。
作为额外的好处，通过识别具有特定需求的特定客户，您可以帮助您的客户避免将所有可能的功能放入工作流引擎中的陷阱“以防万一有人需要”。通过与真实的人讨论真实场景，他们将能够帮助确定谁最需要哪些功能，从而缩小范围并帮助您提供尽可能多的价值。
May I refer you to a post I did quite recently on Acceptance Criteria vs. Scenarios? I think the example might be more illuminating if you use something resembling a specific use of the workflow engine, rather than a generic one. For instance, here's a fake pet shop which I'm using to try out an automation tool. I've then written scenarios around the pet shop, rather than trying to specify generic automation concerns.
If your customers are sometimes in healthcare, for instance, knock up a fake diagnosis tool which uses your engine and write a scenario around that. It might seem like a bit of work to start with, but I've found it pays back for itself very quickly.
This is the benefit you're looking for - that a user gets some information, not that something is stored in a database. As far as possible, a scenario should push for the end value! So maybe it should even say something like:
Any smaller steps which are needed to make this easy and aesthetic are really usability issues. Don't use BDD frameworks to describe usability concerns (though they can step through them, thus giving you your regression tests). Instead, try it manually. BDD isn't a substitute for manual testing, it just helps out a bit.
If you can create a vaguely realistic use of the workflow engine, it'll help you to think of scenarios which you might miss. For instance, I have no idea right now how this workflow can be associated with a particular patient. I find specific, imaginative examples tend to help people visualise other scenarios more than something vague, generic and all-encompassing.
Also, try phrasing it in the same language the business might use, thinking about the business outcomes that you really want. Try not to think about how to implement the scenario - instead, just write it. This will be much, much easier if you actually go and talk to your business people or customers about the scenarios they can think of!
Any complexity needed to make the scenario run then goes into the code, where it's easier to maintain and refactor.
As an additional benefit, by identifying particular customers with particular needs, you can help your customer avoid the trap of putting every possible feature into the workflow engine "in case someone needs it". By talking through real scenarios with real people, they'll be able to help identify who needs which features the most, reducing scope and helping you to deliver as much value as possible.