用於設計表格的黃瓜場景的最佳BDD實踐

Question

假設您有一個可以創建新用戶的表單。 你如何編寫你的黃瓜場景？

1）

Given I am logged in as admin 
When I create a new user 
Then I should see "Successfully created user" 

2）

Given I am logged in as admin 
When I go to Create new user 
And I fill in "Name" with "Name111" 
And I fill in "Password" with "Password111" 
And I press "Create new user" 
Then I should see "Successfully created user" 

如果選擇1）你在哪裏記錄需求的用戶（用戶應該有一個名和密碼） 。我發現BDD是關於行爲的，但在某些時候，您和利益相關者必須指定用戶應該擁有的屬性，不是嗎？

我很新的BDD所以我很感謝任何意見...

Answer 1

您應該閱讀Imperative vs Declarative Scenarios。

--Aslak。黃瓜的創造者。

Answer 2

要麼一會工夫。 ＃1你會創建一個步驟來處理表單的填充。我喜歡的＃1和＃2混合動力，因爲我使用了很多方案概述例如：

Background: 
Given the following users exist: 
    | email    | password  | 
    | test@example.com | testpassword23 | 
    | test2@example.com | notthistime  | 
    | test3@example.com | welcomeback  | 

    @login @authentication 
    Scenario Outline: Authentication 
    Given I am on the new user session page 
    When I login with "<s_email>" and "<s_password>" 
    And I press "Login" 
    Then I should see "<s_message>" 

    Examples: 
    | s_email   | s_password  | s_message      | 
    | test@example.com | testpassword23 | Signed in successfully   | 
    | test2@example.com | itriedreallyhard | Invalid email or password.  | 
    | teOst@example.com | testpassword23 | Invalid email or password.  | 

Answer 3

你寫的場景是相當低的水平。除非你真的在生產安全的登錄功能來銷售，否則我會堅持快樂的情況，其餘的單元/手動測試。如果你不這樣做，你會創造如此多的場景，這將成爲維護的噩夢。

找出您正在創建的產品與所有類似產品的區別，然後將其作爲場景的價值。然後，它會是這樣的：

Given Fred is logged in 
When Fred <does something> 
Then Fred should <get some really differentiating value> 
And <something else happens> 

堅持到真正高層次的能力，而不是低層次的形式爲基礎的步驟。例如：

Given there is already a question on BDD and Cucumber 
Given Peyote is logged in 
When Peyote proposes a question on BDD and Cucumber 
Then Peyote should see other questions on BDD and Cucumber. 

有一個概念叫「頁面範式」，在其中創建一個類的所有低級別步驟的頁面或屏幕可以執行。然後，您可以從更高級別的Cucumber步驟裝置中調用頁面上的這些低級步驟。

您的業務將更多地參與這樣的場景。 BDD的主要目的不是產生自動化測試，而是圍繞場景進行對話，以便在發現執行代碼的麻煩之前，可以找出錯誤的位置以及可以考慮的其他選項。自動化測試是一個很好的副產品。

的交談，而你通過他們說話得學習，有這使得BDD從ATDD（驗收測試驅動開發）不同的事情。這就是爲什麼我們使用這樣的語言示例，場景，給定，何時，然後，上下文，事件，結果而不是測試，安裝，撕下，行爲，安排，斷言 - 所以我們可以談論這些與業務，BA和測試人員使用相同的語言。

見Dan North's article on Deliberate Discovery和他的博客更多的休息，並與BDD好運！