用于设计表格的黄瓜场景的最佳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好运！