将 BDD 功能文件编写得更短、更清晰
我有很多相同的场景，它们只是传递给它们的数据不同。 这是示例：
功能：将报告中的事实链接到 Excel 文档
为了将事实链接到 Excel 文档
作为有权访问报告的用户
我想点击报告中事实的值
场景：任何 uri 项目
鉴于我以管理员身份登录 admin
我选择了示例项目
我选择查看包含来自 factcollection1 以及所有期间和所有客户的数据的报告演示文稿视图
当我单击 Excel 单元格 C2 时
我单击标题为任何 uri 项目的行的第 2 列中的值
然后Excel单元格C2应该包含一些互联网地址值
场景：Base64二进制项目
鉴于我以管理员身份登录 admin
我选择了示例项目
我选择查看包含来自 factcollection1 以及所有期间和所有客户的数据的报告演示文稿视图
当我单击 Excel 单元格 F3 时
我单击标题为 base64 二进制项目的行的第 2 列中的值
那么 Excel 单元格 F3 应包含值 asdf
场景：布尔项
鉴于我以管理员身份登录 admin
我选择了示例项目
我选择查看包含来自 factcollection1 以及所有期间和所有客户的数据的报告演示文稿视图
当我单击 Excel 单元格 J3
我单击标题为布尔项的行的第 2 列中的值
然后 Excel 单元格 J3 应包含值 true
我想将其缩短为如下所示：
场景之前：
鉴于我以管理员身份登录 admin
我选择了示例项目
我选择查看包含来自 factcollection1 以及所有期间和所有客户
场景的数据的报告演示文稿视图：
当我单击 Excel 单元格 XX 时
我单击标题为 ZZ 的行的 YY 列中的值
然后 Excel 单元格 YY 应该包含值 WW
和一些表格数据，例如：
| XX | YY | ZZ | WW |
| C2 | 2 | any uri item | some internet address |
| F3 | 2 | base64 binary item | asdf |
| J3 | 2 | boolean item | true |
我找到了一个解决方案。
有一个具有此能力的场景大纲。
Scenario Outline: display label in selected language
Given I am logged as <username> with <password>
And I have clicked on <button> button
Then result should be some result
Examples:
| username | password | button |
| john | doe | first |
| foo | bar | second |
I have s lot of scenarios that are identical, they only differs by data which are passed to them.
This is example:
Feature: Linking facts from a report into Excel document
In order to link facts to an Excel document
As an user having access to report
I want to click on fact's value in the report
Scenario: Any uri item
Given I am logged as admin with admin
And I have selected Sample Project
And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
When I click on excel cell C2
And I click on the value in 2 column of the row entitled any uri item
Then Excel cell C2 should contain value some internet address
Scenario: Base64 binary item
Given I am logged as admin with admin
And I have selected Sample Project
And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
When I click on excel cell F3
And I click on the value in 2 column of the row entitled base64 binary item
Then Excel cell F3 should contain value asdf
Scenario: Boolean item
Given I am logged as admin with admin
And I have selected Sample Project
And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
When I click on excel cell J3
And I click on the value in 2 column of the row entitled boolean item
Then Excel cell J3 should contain value true
I would like to shorten this to look something like following:
before scenario:
Given I am logged as admin with admin
And I have selected Sample Project
And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
scenario:
When I click on excel cell XX
And I click on the value in YY column of the row entitled ZZ
Then Excel cell YY should contain value WW
and than some table data, like:
| XX | YY | ZZ | WW |
| C2 | 2 | any uri item | some internet address |
| F3 | 2 | base64 binary item | asdf |
| J3 | 2 | boolean item | true |
I found an solution.
There is an scenario outline with this ability.
Scenario Outline: display label in selected language
Given I am logged as <username> with <password>
And I have clicked on <button> button
Then result should be some result
Examples:
| username | password | button |
| john | doe | first |
| foo | bar | second |
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用
Scenario Outline而不是场景。你的例子看起来像这样：You could use
Scenario Outlineinstead ofScenario. Your example would look something like this:这是一个非常有趣的问题，我花了一些时间研究我所说的“数据驱动规范”。这在一定程度上受到许多常见测试框架提供的“行测试”或“数据驱动测试”功能的启发。
我并不是使用同义词“场景”和“规范”，但我更喜欢后者。
与普通单元测试类似，BDD 规范由三部分组成。使用的常见模板是“当 Y 然后 Z 时给出 X”公式。您发现，对于许多规格，“X”部分保持不变。每当我遇到这种情况时，我都会尝试创建一个 Fixture 类来抽象它。例如，这些类之一可能是 LoggedInUserFixture，它设置登录用户并使其可供测试使用。
很多时候，您会发现需要将此灯具与其他灯具组合在一起，以创建适合您的规格的设置。例如，对于单个规范，您可能需要一个
LoggedInUserFixture和一个UserWithSampleProjectSelected。最简单的方法是创建另一个固定装置类，该类将设置其子固定装置并使它们单独可用于您的测试。我仍然抵制提取组合装置的通用模式并让测试框架支持这一点的冲动。
回到使用数据来驱动规范的建议，我认为这是一种有效且有用的模式，我通常让数据驱动我的夹具创建（然后夹具有一个适当的构造函数用于数据注入）。有关详细信息，请参阅 SubSpec 的理论功能。
This is a very interesting question and I have spent some time researching what I call "data driven Specifications". This is partly inspired by the "row-test" or "data-driven-test" features that many common test frameworks offer.
Not that I use the terms "Scenario" and "Specification" synonmous, however I prefer the latter.
Similar to a normal unit test, a BDD specification is composed of three parts. A common template used is the "Given X When Y Then Z" formula. What you have discovered is that for a lot of your specifications the "X" part stays the same. Whenever I encounter such a situation, I try to create a Fixture class to abstract this. For example, one of those classes might be a
LoggedInUserFixturewhich sets up a logged in user and makes it available to the test.Very often, you'll find the need to compose this fixture with other fixtures, to create the setting for your specification. For example you may need a
LoggedInUserFixtureand aUserWithSampleProjectSelectedfor a single Specification. The easiest way to do this is to create another fixture class that will setup its child fixtures and makes them individually available to your test.I am still resisting the urge to extract a common pattern for composing fixtures and make a test framework support this.
To come back to the suggestion to use data to drive specifications, I think it is a valid and useful patterns, I usually make the data drive my fixture creation (the fixture has an appropriate constructor for data injection then). See SubSpec's Theorie feature for details.
这个答案晚了 8 年，但 Gherkin 有办法消除这种重复。它称为场景背景：
更具体地应用于您的情况：
三个常见的
Given步骤移至Background中，然后每个场景都以开始>当。漂亮又整洁。
这比场景大纲更可取的原因是因为您正在处理解析多种类型的数据。据推测，幕后有一些解析逻辑，并且在回归测试期间解析每种数据类型可能会以不同的方式中断。每个测试应该只有一个失败的原因，并且您的原始场景正确地捕获了这一点。
This answer is 8 years too late, but Gherkin has a way of eliminating this duplication. It's called the Scenario Background:
More specifically applied to your situation:
The three common
Givensteps are moved into theBackground, and then each of your scenarios start out with aWhen.Nice and tidy.
The reason this is preferable to a scenario outline is because you are dealing with parsing multiple kinds of data. Presumably there is some parsing logic behind the scenes, and parsing each data type could break in different ways during regression testing. Each test should only have one reason to fail, and your original scenarios properly capture that.