编写真实bdd黄瓜特性/场景的最佳实践

Question

我们是bdd/ cucumber的新手，并在团队中讨论如何编写正确的功能/场景。

我们提出了以下两种方法，这两种方法几乎可以描述/解决相同的需求：

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测试的重点是创建一个规范，说明代码做了什么，您团队中不能阅读代码的人可以阅读这些规范。我会先问他们更喜欢哪一个。

我猜他们会更喜欢第一个，因为它更具说明性。因为它是在更高的抽象级别上编写的(而不是关心单击页面上的小部件)，所以更容易阅读。

与Josh所说的相反，我认为拥有既可以通过UI也可以不通过UI工作的步骤是一个非常好的想法。在功能上出现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 2

一般来说，我会选择更容易被您的客户或开发人员以外的人阅读的解决方案。使用像Cucumber这样的工具的一个很大的优势是它读起来像一个故事。您的目标应该是使每个测试足够简单，以便客户可以阅读您的验收测试，并了解哪些功能已经实现。这会给您带来好处，因为您的客户可以放心，因为他们知道某些功能已经进行了验收测试。

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

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

更容易阅读。

“输入的有效数据和过期日期”

照我的想法。

你不一定需要在每个场景前加上“我能”或“我不能”的前缀，但要慢慢地向一个完整的想法靠拢。

更新

在你的评论中，你问到了验证错误，以及你应该如何使用选项1处理它。我认为你有几个选择：

黄瓜中的Cucumber

• Partial验证测试(错误呈现给用户)中的

1. 完全验证测试，以及RSpec中的部分测试(抛出错误)-或其他一些单元测试框架。

选项1

优点：

您不必费心使用其他框架来测试您的验证。您的大多数测试都将包含在Cucumber中。您的客户可以在一个位置查看您的所有测试。

缺点：

您的Cucumber测试将包含不同级别的粒度。您的客户可能更关心高级功能，而不是查看所有细节。如果我是一个有兴趣使用您的Cucumber测试作为已经实现和测试的功能的基础的客户，我更喜欢一个更小、更具可读性的测试用例列表，而不是一个包罗万象的列表。至多，我可能希望看到错误消息呈现给用户--您可以在一个场景概要中做到这一点。

选项2

优点：

您可以将测试关注点划分为适当的粒度级别。正如我在选项1的缺点中提到的，您的客户最有可能对较高级别的功能感兴趣，而不是对较低级别的细节感兴趣。您可以在RSpec单元测试中测试验证是否通过，并使用Cucumber快速测试如果您有无效的记录，用户是否会看到错误消息(同样使用场景大纲，或者可能只测试是否只有一条验证消息到达前端)。要点是，更多面向功能测试的黄瓜不应该测试与模型有关的每一个小东西-让RSpec或其他单元测试框架来处理。

缺点：

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

据我所知，选项2是目前最受欢迎的。团队使用适合每个粒度级别的框架，并且他们试图远离"all in“方法。

Answer 3

如果你按照黄瓜制造商的标准，第一盘是明显的赢家。

这篇博文，"The training wheels came off" by (其中之一？)黄瓜的制造商(Aslak Helleøy)，直接针对您所写的两个选项之间的差异。他毫不含糊地解释说，声明性的、专注于领域的、易于理解的特性是cucumber的用户应该努力实现的，也是使您的选项1成为赢家的原因。

他基本上是说，试图在系统语言中实现DRY functional步骤(点击这个，选择那个，等等)。是黄瓜中的一种代码气味。用他的话说：

如果你所需要的只是一个驱动鼠标和键盘的测试工具，那就不要使用

。还有其他工具可以用比Cucumber少得多的抽象和类型开销来完成这项工作。

顺便说一句，这里的许多人都说，Cucumber的目的是让客户更容易阅读和理解。我认为这有点偏离目标，易懂不是目的。我认为他们制作Cucumber是为了确保客户和开发人员使用相同的语言，并朝着相同的结果努力。因此，这既是为了帮助客户了解开发过程，也是为了让开发人员站在客户的立场上。