Cucumber BDD和表单字段

我已经阅读了示例规范和几篇BDD文章，它们都说要避免在功能描述和场景中出现诸如特定表单字段之类的细节。但是，如果示例中没有说明我们需要哪些表单字段以及哪些验证是合适的，那么它在哪里呢

我正在考虑将所有表单字段放在场景中，同时为每个验证设置一个场景。这似乎是一个很大的开销；有更好的办法吗

编辑：例如，以以下内容为例

Feature: Add new product

In order to sell a new product on our website
As an internal user
I want to add the product to our catalog

Scenario: Successful addition

Given I am logged in
When I try to add a new product
And I provide "Widget" as the name
And I provide 1 lb. as the weight
And I provide 1 inch as the height
And I provide 2 inches as the width
And I provide 3 inches as the length
Then I see the new product that was added

Scenario: Duplicate name

Given I am logged in
And an existing product named "Dupe"
When I try to add a new product
And I provide "Dupe" as the name
Then I see a duplicate name error

Scenario: Invalid Weight

Given I am logged in
When I try to add a new product
And I provide -1 as the weight
Then I see an invalid weight error

Scenario: Invalid Height

Given I am logged in
When I try to add a new product
And I provide -1 as the height
Then I see an invalid height error

Scenario: Invalid Width

Given I am logged in
When I try to add a new product
And I provide -1 as the width
Then I see an invalid width error

Scenario: Invalid Length

Given I am logged in
When I try to add a new product
And I provide -1 as the length
Then I see an invalid length error

---

我想他们说的是将表单字段放在步骤定义中。例如，而不是

When I put my "Dave" in the username field 
And I put "ou812" in the password field
And I click the Login Button
Then I should see "Dave" in the username field

你应该把

When I log into the site with user "Dave" and password "ou812"
Then I should be logged in as "Dave"

---

使用“^I登录网站…”步骤处理填写字段和单击按钮的详细信息。好处是登录是所需的行为，而字段和按钮是方法。

我想他们说的是将表单字段放在步骤定义中。例如，而不是

When I put my "Dave" in the username field 
And I put "ou812" in the password field
And I click the Login Button
Then I should see "Dave" in the username field

你应该把

When I log into the site with user "Dave" and password "ou812"
Then I should be logged in as "Dave"

---

使用“^I登录网站…”步骤处理填写字段和单击按钮的详细信息。好处是登录是所需的行为，而字段和按钮是方法。

关键是从与特定测试无关的场景中删除所有内容。它们只是分散注意力的噪音。详细信息应在步骤定义中

例如，让我们以这个为例：

Scenario: Successful addition

Given I am logged in
When I try to add a new product
And I provide "Widget" as the name
And I provide 1 lb. as the weight
And I provide 1 inch as the height
And I provide 2 inches as the width
And I provide 3 inches as the length
Then I see the new product that was added

这里有很多重复，而且在风格上完全不是“对话式的”——你不会用这样的语言解释它是如何工作的。给出了具体的尺寸，但没有理由——您将进行其他检查尺寸边界的测试。这里没有测试尺寸。您可以轻松地将其更改为：

Given I am logged in
When I try to add a new product named "Widget"
And specify the weight and dimensions
Then I see the new product that was added

---

这更接近于您向其他人描述测试的方式，并且隐藏了步骤定义中的详细信息。

关键是从场景中删除与特定测试无关的所有内容。它们只是分散注意力的噪音。详细信息应在步骤定义中

例如，让我们以这个为例：

Scenario: Successful addition

Given I am logged in
When I try to add a new product
And I provide "Widget" as the name
And I provide 1 lb. as the weight
And I provide 1 inch as the height
And I provide 2 inches as the width
And I provide 3 inches as the length
Then I see the new product that was added

这里有很多重复，而且在风格上完全不是“对话式的”——你不会用这样的语言解释它是如何工作的。给出了具体的尺寸，但没有理由——您将进行其他检查尺寸边界的测试。这里没有测试尺寸。您可以轻松地将其更改为：

Given I am logged in
When I try to add a new product named "Widget"
And specify the weight and dimensions
Then I see the new product that was added

---

这更接近于您向其他人描述测试的方式，并隐藏了步骤定义中的细节。

假设有20个附加字段，如价格、描述、制造商等。现在，我相信Cucumber的目的是让业务人员能够编写场景，而开发人员或测试工程师将编写步骤定义。如何将特定领域从业务部门传达给团队？我的印象是黄瓜可以作为规范，但它似乎不完整。团队通常会有额外的外部文档，还是只是在对话中？如果有其他字段，你会口头上说你将如何测试它们？也许你会说“确保FieldA、FieldB和FieldC是必填字段”，编写一个涵盖这一点的场景很容易。话虽如此，我从来没有完全依赖Cumber规范，通常每个故事都有用户故事，每个故事都有接受标准，场景就是其中的一部分。几年后，我再次强调这一点：Cumber是面向客户的（这是他们理解的，不一定要写）。它不是一个单元测试框架。我遇到过太多的具体情况。客户没有发现它们的价值，开发人员不得不不断修复它们。没人高兴。请保持Cumber测试的高水平。假设有20个附加字段，如价格、描述、制造商等。现在，我相信Cumber的目的是让业务人员能够编写场景，而开发人员或测试工程师将编写步骤定义。如何将特定领域从业务部门传达给团队？我的印象是黄瓜可以作为规范，但它似乎不完整。团队通常会有额外的外部文档，还是只是在对话中？如果有其他字段，你会口头上说你将如何测试它们？也许你会说“确保FieldA、FieldB和FieldC是必填字段”，编写一个涵盖这一点的场景很容易。话虽如此，我从来没有完全依赖Cumber规范，通常每个故事都有用户故事，每个故事都有接受标准，场景就是其中的一部分。几年后，我再次强调这一点：Cumber是面向客户的（这是他们理解的，不一定要写）。它不是一个单元测试框架。我遇到过太多的具体情况。客户没有发现它们的价值，开发人员不得不不断修复它们。没人高兴。请保持黄瓜测试的高水平。