【问题标题】:Valid BDD Scenario Steps? Given -> When -> Then -> When有效的 BDD 方案步骤?给定 -> 何时 -> 然后 -> 何时
【发布时间】:2014-05-24 21:58:56
【问题描述】:

如果我定义了以下步骤,这是否有效?我觉得是某种气味。

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   |

【问题讨论】:

    标签: bdd


    【解决方案1】:

    Liz 对系统功能的描述是正确的。我还建议在场景中只有一个When。因为每个场景(我认为)都应该验证系统从 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   |
    

    在这种情况下,当其中一个场景发生故障时,您就会知道原因。它要么没有改变用户的状态,要么没有正确过滤它们。您知道您的应用程序中的哪个功能被破坏了。

    【讨论】:

      【解决方案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   |
      

      您还可以使用更典型的用户名,以便阅读它的人一目了然地理解这些名称所代表的含义(Lunivore、Soe、Jon 而不是 u1 和 u2)。

      差别不大。你认为什么是难闻的气味?只是语言吗?

      【讨论】:

        【解决方案3】:

        通常最好只有一个“何时”步骤,因为那是您实际测试的内容。但是,有时我发现指定可能包括几个相互依赖的 then 和 when 步骤的整个用例也很有用。例如:

         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 
        

        但是,在您的示例中,您确实应该编写两个测试,因为您实际上测试了两个不直接相互依赖的不同功能。

        【讨论】:

          猜你喜欢
          • 2018-11-13
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2020-06-17
          • 2020-10-14
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多