Valid BDD Scenario Steps? Given -> When -> Then -> When

问题

If I have the following steps defined, is this valid scenario? I feel like it is some kind of smell.

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   |

回答1:

Liz is right about describing capabilities of system. I would also suggest to have only one When in scenario. Because each scenario (I think) should verify that system goes from Given state to Then state When something happens.

In this case I also suggest to have two different features. One feature is about your application can change user status (activate/deactivate):

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   |

Another feature is about you can filter users by status:

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   |

In this case when one of the scenarios is broken, you will know the reason. It's either not changing status of user, or not filtering them properly. You know which feature is broken in your application.

回答2:

You're describing it in quite code-driven terms, but otherwise it's a valid scenario.

If you wanted to make it better, you could describe it in terms of the capabilities of the system, in the language that users might use to describe what they're doing:

Scenario: Change users status
   Given these users exist:
        | code | status   |
        | u1   | active   |
        | u2   | inactive |
        | u3   | active   |
    And we filter for active users
    When I disable user u1
    Then I should see the following users:
        | code |
        | u3   |
    When we filter for inactive users
    Then I should see the following users:
        | code |
        | u1   |
        | u2   |

You could also use more typical usernames so that people reading it understand what those names represent at a glance (Lunivore, Soe, Jon instead of u1 and u2).

Not so much difference. What did you identify as a bad smell? Was it just the language?

回答3:

Typically it is good to just have one 'when' step, because that is what you actually test. However, sometimes I find it also useful to specify whole use cases that might include several then and when steps that depend on each other. For example:

 when a new user registers
 then the user receives an email confirmation
 when the email confirmation is confirmed by the user
 then the user is registered 

In your example, however, you really should write two tests, because you actually test two different features that also do not directly depend on each other.

来源：https://stackoverflow.com/questions/3616499/valid-bdd-scenario-steps-given-when-then-when