有效的BDD场景步骤？给出 - >当 - >然后 - >当

Question

如果我定义了以下步骤,这是有效的方案吗？我觉得这是某种气味.

Scenario: Change users status
   Given I have the following users exist:
        | code | status   |
        | u1   | active   |
        | u2   | inactive |
        | u3   | active   |
     And the status filter is "active"
    When I update "u1" to "inactive" 
    Then I should see the following users:
        | code |
        | u3   |
    When I change status filter to "inactive"
    Then I should see the following users:
        | code |
        | u1   |
        | u2   |

Answer 1

Liz正确地描述了系统的功能.我还建议在场景中只有一个.因为每个场景(我认为)应该验证系统是否从Given状态变为Then状态何时发生.

在这种情况下,我还建议有两个不同的功能.一个功能是关于您的应用程序可以更改用户状态(激活/停用):

Feature: Changing user status

Scenario: Deactivating user
   Given following users exist:
        | code | status   |
        | u1   | active   |
        | u2   | inactive |
        | u3   | active   |
    When user u1 is deactivated
    Then following users exist:
        | code | status   |
        | u1   | inactive |
        | u2   | inactive |
        | u3   | active   |

另一个功能是您可以按状态过滤用户:

Feature: Filtering users

Scenario: Filtering active users
   Given following users exist:
        | code | status   |
        | u1   | active   |
        | u2   | inactive |
        | u3   | active   |
    When I filter for active users
    Then I should see the following users:
        | code |
        | u1   |
        | u3   |

Scenario: Filtering inactive users
   Given following users exist:
        | code | status   |
        | u1   | active   |
        | u2   | inactive |
        | u3   | active   |
    When I filter for inactive users
    Then I should see the following users:
        | code |
        | u2   |

在这种情况下,当其中一个场景被打破时,您就会知道原因.它要么不改变用户的状态,要么不正确地过滤它们.您知道应用程序中哪个功能已损坏.