最好的做法，写真正的bdd黄瓜功能/场景

Question

我们是新的bdd /黄瓜和讨论在队伍中如何编写正确的功能/场景。

我们想出了两个下列办法，几乎应该说明/解决同样的要求：

Feature: Give access to dossiers to other registered users 
    As a logged in user 
    In order to show my dossier to other users 
    I want to give other users (limited) access to my dossiers 

    Background: 
    Given I am logged in as "Oliver" 
    And another user "Pascal" exists 
    And another user "Tobias" exists 

    Scenario: I can give access to my own dossier 
    When I grant access to "Pascal" with permisson "readonly" 
    Then I should see "Access granted." 
    And user "Pascal" should have permission "readonly" on dossier "Oliver" 

    Scenario: I can give access to a created dossier 
    Given I created a new dossier "Max Müller" 
    When I grant access on dossier "Max Müller" to "Pascal" with permisson "readonly" 
    Then I should see "Access granted." 
    And user "Pascal" should have permission "readonly" on dossier "Max Müller" 

    Scenario: I can give access to a managed dossier 
    Given I manage the dossier from "Tobias" 
    When I grant access on dossier "Tobias" to "Pascal" with permisson "readonly" 
    Then I should see "Access granted." 
    And user "Pascal" should have permission "readonly" on dossier "Tobias" 

    Scenario: I cannot give access to a writable dossier 
    Given I have write access to the dossier from "Tobias" 
    When I follow "Grant access" 
    Then I should see "You are not allowed to grant access on this dossier." 

    Scenario: I cannot give access to a readonly dossier 
    Given I have readonly access to the dossier from "Tobias" 
    When I follow "Grant access" 
    Then I should see "You are not allowed to grant access on this dossier." 

    Scenario: I can give access to a dossier with an expiration date 
    Given I created a new dossier "Max Müller" 
    When I grant access on dossier "Max Müller" to "Pascal" with permisson "readonly" until "2020-01-01" 
    Then I should see "Access granted till 2020-01-01." 
    And user "Pascal" should have permission "readonly" on dossier "Max Müller" until "2020-01-01" 

    Scenario: I cannot transfer a created dossier to a new owner who is already registered 
    Given I created a new dossier "Max Müller" 
    When I transfer dossier "Max Müller" to "Pascal" 
    Then I should see "Pascal already has a dossier, transfer not possible." 

第二个：

Feature: Grant access on dossiers to registered users 
    As a logged in user 
    In order to allow others to view/ manage dossiers I have access to 
    I want to give access of those to other users 

    Background: 
    Given I am logged in as "gucki@email.com" 
    And I am working with my own dossier 

    Scenario: Invalid data entered 
    When I visit the grant dossier access page 
    And I press "Grant access" 
    Then I should see a validation error on "eMail-Address" 

    Scenario: Valid data entered 
    Given a user "pascal@email.com" exists 
    When I visit the grant dossier access page 
    And I fill in "eMail-Address" with "pascal@email.com" 
    And I select "readonly" from "Permissions" 
    And I press "Grant access" 
    Then I should see "Access granted." 
    And I should be on the dossiers page 

    Scenario: Valid data entered with expiry date 
    Given a user "pascal@email.com" exists 
    When I visit the grant dossier access page 
    And I fill in "eMail-Address" with "pascal@email.com" 
    And I select "readonly" from "Permissions" 
    And I fill in "Valid until" with "2010-03-01" 
    And I press "Grant access" 
    Then I should see "Access granted till 2010-03-01." 
    And I should be on the dossiers page 

    Scenario: Display calendar on click on "Valid until" 
    When I click on the field "Valid until" 
    Then a calendar popup should be displayed 
    When I click on "1943-01-02" 
    Then the field "Valid until" should be have "1943-01-02" 
    And the calendar popup should be hidden 

    Scenario: Only allow to grant access to categories I have access to myself 
    Given I have limited access to the working dossier 
    When I visit the grant dossier access page 
    Then I should not see categories I have no access to 

    Scenario: Dossier with permission "manager" can only grant readonly, readwrite 
    Given I have the permission "manager" on my working dossier 
    When I visit the grant dossier access page 
    Then I should only see the permissions "readonly, readwrite" 

    Scenario: Dossier with permission "readwrite" is not allowed to grant any permissions 
    Given I have the permission "readwrite" on my working dossier 
    When I visit the grant dossier access page 
    Then I should the see the error "You cannot grant access on this dossier!" 
    And I should be on the dossiers page 

一个你会喜欢哪一种？为什么？

Answer 1

我会选择一种更易于客户或开发者以外的人阅读的解决方案。使用像Cucumber这样的工具的一大优点是它看起来像一个故事。您的目标应该是使每个测试都足够简单，以便客户可以阅读您的验收测试并了解哪些功能已经实施。这对您有好处，因为您的客户可以轻松地知道某些功能具有验收测试。

话虽如此，我认为第一个解决方案比第二个解决方案更能代表可读的风格。

“我可以给访问的档案与 到期日期”

是很容易，

“与到期日期输入有效的数据” 读

在我看来。

你不一定需要在每个场景前面添加“我可以”或“我不能”，但是可以放在一个完整的想法旁边。

更新

在你的评论被问及验证错误，你应该如何处理与选项1.我觉得你有几个选择这里：

1. 黄瓜全面验证测试
2. Cucumber中的部分验证测试（向用户显示错误），RSpec中的部分测试（引发错误） - 或其他单元测试框架。

选项1

优点：

您不必使用其他框架来测试您的验证打扰。你的大部分测试将被包含在黄瓜中。您的客户可以在一个地方看到所有的测试。

缺点：

您黄瓜的测试将具有粒度的不同级别包括在内。您的客户可能更关心高级功能，而不是看到所有细节的细节通过。如果我是一个有兴趣使用Cucumber测试作为已经实现和测试过哪些功能的基础的客户，我宁愿选择比所有测试案例更小，更易读的测试案例列表。我最多可能希望看到错误消息呈现给用户 - 您可以在一个场景大纲中执行此操作。

选项2

优点：

你分开你的测试问题纳入粒度的适当水平。正如我在选项1中提到的那样，您的客户很可能对较低级别的细节感兴趣。您可以在RSpec单元测试中测试验证是否通过，并且使用Cucumber快速测试用户是否看到错误消息（如果有无效记录）（再次使用场景轮廓，或者只是测试以查看是否只有一条验证消息它到前端）。主要的观点是更多功能测试的Cucumber不应该测试关于Models的每一件小事情 - 让RSpec或其他单元测试框架来处理它。

缺点：

你必须使用另一个框架行使更细粒度的预期。使用另一个框架意味着需要花费更多的时间来学习它等等。另外，很难知道如何平衡何时使用一个框架，即“我应该在这里使用Cucumber还是RSpec？”。

从我读过的，选项2是目前最流行的。团队使用适合每个粒度级别的框架，他们试图远离“全进”方法。

Answer 2

我更喜欢第一种方案，因为它在一个更好的办法的功能是如何工作的

此外，你必须测试的重构与方案纲要在那里做，检查本博客文章介绍，这是伟大的工作黄瓜http://eggsonbread.com/2010/09/06/my-cucumber-best-practices-and-tips/

在第一种方法，你必须做你自己的步骤，但你会使用更多的时间相同的情况下，减少代码重复，当你有：

我填写“电子邮件地址”与“pascal@email.com” 而我填写“电子邮件地址”w ith“tobias@email.com”

在不同的情况下。我希望在这里指出我的观点。

此外，我强烈建议您the rspec book和talk called outside-in development with cucumber

问候

Answer 3

这种BDD的整点是对于非技术决策者提供可读的，可以理解的规格/校长组织内（以减少决策者和执行者之间的沟通困境）。

为此，您的第一个示例中的样式对于第二个示例而言是无可挑剔的。简单。

Answer 4

我更喜欢两者的第二种方法。这是我对方法1的担忧。

当我授予档案存取“最大 穆勒”到“帕斯卡”与在未经许可的 “只读”

可以不通过用户界面，这是一个危险的去实现。如果对用户授予访问权限的方式有一个完整的期望，那么这些期望就不会被测试。黄瓜的光芒正在从UI向下测试（通过UI进行测试）。

我对

而且用户“帕斯卡”同样值得关注应该有 许可“只读”的档案“最大 穆勒”

有可能要实施的每个步骤在步骤定义中通过调用通过UI执行的步骤，但除非这是真的，否则我仍然会有这种担忧。

总之，我担心方法1不会通过UI进行测试。

Answer 5

编写Cucumber测试的要点是创建一个关于您的团队中无法读取代码的人员可以读取代码的规范。我会先问他们哪一个更喜欢。

我的猜测是他们会更喜欢第一个，因为它更具说明性。因为它是在更高的抽象层次上编写的（而不是关心点击页面上的小部件），所以它更易于阅读。

与乔什说的相反，我认为有步骤可以通过用户界面或无法工作是一个非常好的主意。曲面UI对功能的担忧可能会使设计更改变得很脆弱，而且阅读起来也很枯燥。

我最近做了一个谈论这个问题上，我认为这是你在哪里真正相关： http://skillsmatter.com/podcast/agile-testing/refuctoring-your-cukes

又见这些相关的博客文章：

• http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html
• http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/
• http://elabs.se/blog/15-you-re-cuking-it-wrong

祝你好运！

Answer 6

如果按照黄瓜制造商的标准行事，第一套就是明确的赢家。

这篇博客文章，"The training wheels came off"作者是（黄金制造商之一）（AslakHellesøy）的作者之一，主要针对你写的两个选项之间的区别。毫不含糊地说，他解释说，以陈述性，领域为中心，易于理解的特征是黄瓜用户应该努力达到的目标，并且使得你的选择1成为赢家。

他基本上说，努力实现在系统语言DRY 功能步骤（点击此，选择等）黄瓜代码气味。用他的话说：

如果你需要的是用于驱动鼠标和键盘测试工具， 不要用黄瓜。还有其他的工具可以用来完成这个工作，而且这个工具的抽象和打字费用远低于Cucumber。

顺便说一下，这里很多人都说过，黄瓜的目的是为了让顾客更容易阅读和理解。我认为这是略微偏离目标，理解的难易不是目的。我认为他们让Cucumber确保客户和开发人员使用相同的语言并努力获得相同的结果。因此，让开发人员进入客户的行列就像帮助客户了解开发流程一样。