Действительные шаги сценария 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

Лиз права в описании возможностей системы.Я бы также предложил иметь только один вариант «В сценарии».Потому что каждый сценарий (я думаю) должен проверять, что система переходит из данного состояния в состояние затем, когда что-то происходит.

В этом случае я также предлагаю иметь две разные функции.Одна функция о том, что ваше приложение может изменять статус пользователя (активировать / деактивировать):

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   |

В этом случае, когда одиниз сценариев не работает, вы будете знать причину.Это либо не меняет статус пользователя, либо не фильтрует их должным образом.Вы знаете, какая функция не работает в вашем приложении.

Answer 2

Вы описываете это в терминах, основанных на коде, но в остальном это правильный сценарий.

Если вы хотите улучшить его, вы можете описать его в терминах возможностей системы, на языке, который пользователи могут использовать для описания своих действий:

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   |

Вы также можете использовать более типичные имена пользователей, чтобы люди, читающие их, сразу поняли, что эти имена представляют (Лунивор, Со, Джон вместо u1 и u2).

Не так много различий. Что вы назвали плохим запахом? Это был только язык?

Answer 3

Как правило, хорошо иметь только один шаг «когда», потому что это то, что вы на самом деле тестируете.Тем не менее, иногда я нахожу также полезным указать целые варианты использования, которые могут включать несколько тогда и когда этапы, которые зависят друг от друга.Например:

 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 

Однако в вашем примере вы действительно должны написать два теста, потому что вы на самом деле тестируете две разные функции, которые также напрямую не зависят друг от друга.