最好的做法，寫真正的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確保客戶和開發人員使用相同的語言並努力獲得相同的結果。因此，讓開發人員進入客戶的行列就像幫助客戶瞭解開發流程一樣。