问题描述
我正在尝试编写多步骤业务流程的需求(通过向导).在很多情况下，用户与一个屏幕的交互都会改变是否允许您在另一屏幕上选择选项.
I am trying to write requirements for a multi-step business process (via a wizard). I have many scenarios where user interactions with one screen will change whether you are allowed to pick options on another screen.
例如(我遮住了实际的业务，但是步骤的过程和形式几乎相同):
For example (I've obscured the actual business, but the process and form of the steps is nearly identical):
Feature: Personal Diagnostic Search Filter
In order to select a Technician who offers Personal Diagnostics,
when I've asked for a Personal Diagnostic
As a Business Customer
I want to limit my search to Technicians who offer Personal Diagnostics
Background:
Given a Business named "Big Al's Auto Supply"
And a Customer named "Bob Test" at the "Big Al's Auto Supply" Business
And an Account named "[email protected]" owned by "Bob Test"
And the "[email protected]" Account has the "Repair Order Creator"
permission
And you log in as "[email protected]"
And you start scheduling a new Repair Order
Scenario: Enter the Select Technician page when Use PD is selected
Given you select Use PD
When you enter the Select Technician page
Then the PD Filter should be visible
And the PD Filter should be selected
Scenario: Basic Search for Technicians when PD Filter is selected
Given a Technician named "PD Technician"
And the Technician named "PD Technician" supports PD
And a Technician named "Non-PD Technician"
And the Technician named "Non-PD Technician" does not support PD
And you select Use PD
And you enter the Select Technician page
And you select the PD Filter
And you select Basic Search
When you search for Technicians with the name "Technician"
Then your search results should contain "PD Technician"
And your search results should not contain "Non-PD Technician"
但是在小黄瓜Wiki 上，建议您:
尽管如此，他们还是例外:
They go on to make an exception, though:
在该页面上还说:
如果您需要进行大量的UI交互，那么给定"中的内容和何时"中的内容?
在我的第一种情况下，select Use PD需要UI交互，因为它是用于创建新维修单的向导的一部分.但是，这是显示PD筛选器的前提，并且在用户进入选择技术人员"页面时触发.
In my first scenario, select Use PD requires UI interaction, as it is part of the wizard for creating a new Repair Order. However it is a precondition for PD Filter to be visible, and is triggered when the user enters the Select Technician page.
第一种情况可能还不错，但是第二种情况使问题更加严重.当您点击 Search 时会触发搜索，但是要导航到该页面，必须完成许多UI交互.其中一些交互也无法掩盖，因为必须选择Use PD才能使搜索过滤器均匀显示.但是这些UI交互不是该场景的关键操作.
The first scenario might not be so bad, but the second scenario exacerbates the problem. The search is triggered when you hit Search but there are a lot of UI interactions that must be done to navigate to that page. Some of those interactions can't be glossed over, either, as Use PD must be selected for the search filter to even appear. But those UI interactions aren't the key action of the scenario.
推荐答案
作为一般规则，请尽可能多地用语表达场景，好像您正在与之对话一样，并尽可能多地排除不相关的信息
As a general rule, try as much as possible to phrase the scenario as if you're having a conversation about it, and exclude as much irrelevant information as possible.
例如，我希望您的上述情况能读到以下内容:
For instance, I would love your scenarios above to read something like:
Given our customer Bob Test is scheduling a repair order
And we have two technicians: "Fred Technician" and "George Nontechnician"
When Bob Test decides he wants a Personal Diagnostic
And he selects a technician
Then the search results should only contain "Fred Technician"
然后执行使这些步骤起作用的所有必要操作-无论是登录还是其他方式.请注意，我没有谈论页面"，也没有采取实际步骤-用户应该直观地理解它们. BDD与测试无关.这是关于提出人们如何使用该系统的示例，以便您可以围绕这些示例进行对话并进行探索，找到异常和不同的情况等.
Then do whatever is necessary to make those steps work - be they logging in or otherwise. Notice I haven't talked about "pages", or taken the actual steps - they should be intuitive for the user. BDD isn't about testing. It's about coming up with examples of how people are going to use the system, so that you can have conversations around those examples and explore them, find exceptions and different scenarios, etc.
检查过滤器是否可见没有价值.用户不在乎过滤器是否可见.他很在乎可以使用过滤器来获取结果，所以就这样做.
Checking that the filter is visible is not valuable. The user doesn't care that the filter is visible. He cares that he can use the filter to get his results, so just do that.
在代码中，我通常在步骤之间传递一个世界"对象.这样可以消除很多麻烦.我没用过小黄瓜，但我想它提供了类似的功能.您可以在其中存储所有用户详细信息，您已经创建了哪些技术人员，以便可以检查其是否不会在结果中返回"George Nontechnician"，等等.
In the code, I usually pass a "World" object between my steps. That can get a lot of the gubbins out of the way. I haven't used Gherkin much but I imagine it provides for a similar ability. You can store all the user details in there, which technicians you've created so that you can check it doesn't bring back "George Nontechnician" in the results, etc.
使用角色的友好名称也很有用，因为人们可以想象弗雷德和乔治的模样.
Using friendly names for roles is useful too, because people can then imagine what Fred and George look like.
摆脱一切不会对场景产生影响的东西，也不会帮助人们想象发生的一切.您知道Bob有权安排订单，因为那是他的工作-只需在该步骤中添加必要的内容即可.
Get rid of anything which isn't going to make a difference in the scenario and isn't going to help people imagine it happening. You know that Bob has permission to schedule an order because that's what he's doing - just add the necessary stuff to that step.
何时"是您要描述的行为.在这种情况下，您会对筛选个人诊断"的能力感兴趣，因此与行为相关的所有用户交互都应在何时"中，而所有先前的交互都应在给定"中.我发现尝试考虑结果不同的环境很有用-例如，如果没有可用的PD技术人员会发生什么?这告诉我区别是什么；我们将设置一个不同的 context ，但执行相同的 event .上下文在给定中，事件在时间中. (在引入背景"之前，这通常要简单得多.)
The "When" is the behavior you're interested in describing. In this case, you're interested in the ability to filter for Personal Diagnostics, so all the user interaction associated with behavior should be in the "When", and all previous interaction should be in the "Givens". I find it useful to try and think of a context in which the outcome is different - for instance, what happens if there are no PD technicians available? That tells me what the difference is; we'll be setting up a different context but performing the same event. Context goes in the Given, events go in the When. (This used to be much simpler before "Background" was introduced).
通常，如果您在观看场景时眼神呆滞，那说明您做错了事.
In general, if your eyes glaze over when you look at a scenario, you're doing something wrong.
希望这会有所帮助.
这篇关于编写BDD功能时，我应该将先前的用户交互放入“给定"步骤还是“何时"步骤?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！