黄瓜特征文件中应提供多少数据?
How much data should be given in a cucumber feature file?
我正在尝试编写一些 Gherkin 功能文件,以便使用 SpecFlow 进行 BDD 验收测试。我正在尝试测试的系统由多个 RESTful API 组成 - 系统具有微服务架构。在一个场景中,我需要确定一些记录在进行实际场景之前已经存在于数据库中,因此我包含了一个 Background
部分和一个 given
部分。我遇到的问题是,每条需要存在的记录都是通过 API 创建的,这些 API 在其模式联系人中需要大量数据,并且团队要求我在小黄瓜的记录中指定每个字段及其各自的值table。结果是这样的:
| PassportExpireDate|PassportNumber|PassportCountry |Firstname|Lastname|LocalFirstname|LocalLastname | Birthday | NationalNumber | NationalityCountryId | PassengerType | Gender |PartyId | SourceTravelerId | CellNumber | Price|
这是我的 table 之一的 header,它将用于在开始按规范进行实际测试之前在数据库中创建 Traveler 记录。但是,如您所见,table 字段太多,因此太长,太适合屏幕显示,因此很难阅读和维护。其次,它与 DTO 模式紧密耦合。我争辩说我们不应该在我们的规范中加入这么多细节,试图只包括重要的 high-level 数据(例如,假设我们有一个名为 "James Peterson" 的现有旅行者)但团队和 CTO 坚持认为这些细节应该出现在功能文件中。在我的下一次尝试中,我将 table 分解为多个 table(例如个人数据、订单数据、护照数据等)。
但我仍然很困惑,我认为我仍然没有做任何事情。你有什么建议?我们对此有什么经验法则或最佳做法吗?
你能像下面这样转置数据 table 中的字段和值吗?
|field |values |
| PassportExpireDate |[] |
| PassportNumber |[] |
| PassportCountry |[] |
| Firstname |[] |
| Lastname |[] |
| LocalFirstname |[] |
| LocalLastname |[] |
| Birthday |[] |
| NationalNumber |[] |
| NationalityCountryId |[] |
| PassengerType |[] |
| Gender |[] |
| PartyId |[] |
| SourceTravelerId |[] |
| CellNumber |[] |
| Price |[] |
并在步骤 def 中实现从值数组中获取值的逻辑。
Specflow 支持此类情况的外部数据绑定。您可以使用 Excel binding 来保持您的功能文件合适。
Scenario Outline: Add Traveler
Given ...
When ....
Then ....
@source:TravelerRecordsExamples.xlsx
Examples:
| PassportExpireDate|PassportNumber|PassportCountry |Firstname|Lastname|LocalFirstname|LocalLastname | Birthday | NationalNumber | NationalityCountryId | PassengerType | Gender |PartyId | SourceTravelerId | CellNumber | Price|
TLDRNone
不要将定义和数据放在 Gherkin 表中,这会适得其反并且容易出错。而是使用其他东西来指定字段(最好是 api 的源代码)并命名每个东西。
然后使用简单的 Givens 为您创造东西。
现在您的情况似乎是在创建旅行者。你的小黄瓜记录的行为是旅行者的创造。旅行者是如何被创造出来的,他们的特征是什么,在这种行为的描述中没有位置。
所以你的后台步骤变成了
Given there are foo travelers
实现类似于
Given 'there are foo travelers' do
create_foo_travelers
end
现在你已经翻译了你的问题
from
How do I do something incredibly stupid and difficult in Gherkin
to
How do I write some code to create travelers
这是您编写 Cuking 时应该采用的所有场景的方法。场景应该只记录行为的内容和原因。有关如何实现行为的任何详细信息在场景中都没有位置。
cuking 的真正力量在于使用自然语言、命名和抽象来让 cukes 变得简单。使用这些技能将 HOW 的复杂性委托给更合适的工具。
我正在尝试编写一些 Gherkin 功能文件,以便使用 SpecFlow 进行 BDD 验收测试。我正在尝试测试的系统由多个 RESTful API 组成 - 系统具有微服务架构。在一个场景中,我需要确定一些记录在进行实际场景之前已经存在于数据库中,因此我包含了一个 Background
部分和一个 given
部分。我遇到的问题是,每条需要存在的记录都是通过 API 创建的,这些 API 在其模式联系人中需要大量数据,并且团队要求我在小黄瓜的记录中指定每个字段及其各自的值table。结果是这样的:
| PassportExpireDate|PassportNumber|PassportCountry |Firstname|Lastname|LocalFirstname|LocalLastname | Birthday | NationalNumber | NationalityCountryId | PassengerType | Gender |PartyId | SourceTravelerId | CellNumber | Price|
这是我的 table 之一的 header,它将用于在开始按规范进行实际测试之前在数据库中创建 Traveler 记录。但是,如您所见,table 字段太多,因此太长,太适合屏幕显示,因此很难阅读和维护。其次,它与 DTO 模式紧密耦合。我争辩说我们不应该在我们的规范中加入这么多细节,试图只包括重要的 high-level 数据(例如,假设我们有一个名为 "James Peterson" 的现有旅行者)但团队和 CTO 坚持认为这些细节应该出现在功能文件中。在我的下一次尝试中,我将 table 分解为多个 table(例如个人数据、订单数据、护照数据等)。
但我仍然很困惑,我认为我仍然没有做任何事情。你有什么建议?我们对此有什么经验法则或最佳做法吗?
你能像下面这样转置数据 table 中的字段和值吗?
|field |values |
| PassportExpireDate |[] |
| PassportNumber |[] |
| PassportCountry |[] |
| Firstname |[] |
| Lastname |[] |
| LocalFirstname |[] |
| LocalLastname |[] |
| Birthday |[] |
| NationalNumber |[] |
| NationalityCountryId |[] |
| PassengerType |[] |
| Gender |[] |
| PartyId |[] |
| SourceTravelerId |[] |
| CellNumber |[] |
| Price |[] |
并在步骤 def 中实现从值数组中获取值的逻辑。
Specflow 支持此类情况的外部数据绑定。您可以使用 Excel binding 来保持您的功能文件合适。
Scenario Outline: Add Traveler
Given ...
When ....
Then ....
@source:TravelerRecordsExamples.xlsx
Examples:
| PassportExpireDate|PassportNumber|PassportCountry |Firstname|Lastname|LocalFirstname|LocalLastname | Birthday | NationalNumber | NationalityCountryId | PassengerType | Gender |PartyId | SourceTravelerId | CellNumber | Price|
TLDRNone
不要将定义和数据放在 Gherkin 表中,这会适得其反并且容易出错。而是使用其他东西来指定字段(最好是 api 的源代码)并命名每个东西。
然后使用简单的 Givens 为您创造东西。
现在您的情况似乎是在创建旅行者。你的小黄瓜记录的行为是旅行者的创造。旅行者是如何被创造出来的,他们的特征是什么,在这种行为的描述中没有位置。
所以你的后台步骤变成了
Given there are foo travelers
实现类似于
Given 'there are foo travelers' do
create_foo_travelers
end
现在你已经翻译了你的问题
from
How do I do something incredibly stupid and difficult in Gherkin
to
How do I write some code to create travelers
这是您编写 Cuking 时应该采用的所有场景的方法。场景应该只记录行为的内容和原因。有关如何实现行为的任何详细信息在场景中都没有位置。
cuking 的真正力量在于使用自然语言、命名和抽象来让 cukes 变得简单。使用这些技能将 HOW 的复杂性委托给更合适的工具。