如何编写以先前功能为基础的黄瓜测试? [英] How Do I Write Cucumber Tests That Build On Previous Features?

问题描述

我已经开始使用Cucumber编写BDD测试以匹配我的应用程序的业务用例.它基于区块链，因此测试中的每个用户都在运行该应用程序的实例.这也意味着每次测试都非常繁琐，并且95％的测试时间都在设置阶段.

I have started using Cucumber to write BDD tests to match the business use cases for my application. It is blockchain based so each user in the test is running an instance of the application. This also means that each test is quite heavy and 95% of the test time is in the setup stage.

在编写测试时，我发现我开始重复自己，而且以前的功能似乎变得多余了.

As I write the tests I am finding that I am starting to repeat myself and the earlier features are seemingly becoming redundant.

一个业务流程是:

• User1保存一条新消息
• User2编辑消息
• User1验证修改
• User1取消邮件
• User2确认取消

这分为新功能/编辑功能/取消功能.

This gets broken down into New/Edit/Cancel features.

最初，我从新建"和编辑"功能文件开始，如下所示:

Initially I started out with "New" and "Edit" feature files looking like this:

新

Feature: a new message is added

  Scenario: a user adds a new message
    Given there is a user called User1
    And there is a user called User2
    When User1 creates a new message with id 1234
    Then User2 should see the message with id 1234

修改

Feature: Editing a message

  Scenario: A User edits a message
    Given there is a user called User1
    And there is a user called User2
    When User1 creates a new message with id 1234
    And User2 adds the location US to the message
    Then User1 should see the location US on the message

但是现在我要进入取消"部分，我意识到，要正确测试取消"，系统需要有一条已编辑的消息，这意味着我需要经历新建"和编辑"功能才能将消息输入正确的状态.

But now I am coming on to the Cancel part I realise that in order to test the Cancel properly, the system needs to have an edited message which means I need to have gone through the New and Edit features to get the message into the right state.

这会使取消"看起来像这样，然后开始变得很长:

This would make the Cancel look something like this, which then is starting to get quite lengthy:

取消

Feature: Cancelling a message

  Scenario: A User cancels a message
    Given there is a user called User1
    And there is a user called User2
    When User1 creates a new message with id 1234
    And User2 adds the location US to the message
    And User1 cancels the message
    Then User2 should see status Cancelled on the message

我可以这样写取消":

Feature: Cancelling a message

  Scenario: A User cancels a message
    Given there is a message with id 1234
    And User1 cancels the message
    Then User2 should see status Cancelled on the message

作为一项功能读起来相当不错，但是，我现在必须为有一条ID为1234的消息"编写一个步骤定义，以完成编辑功能所做的所有工作.

which reads quite well as a feature, however, I would now have to write a step definition for "there is a message with id 1234" that does everything that the Edit feature was doing.

如开始所述，这些测试中的设置花费了95％的测试时间，因此理想情况下，我希望将它们作为一系列步骤一起运行，而不是从每个功能重新开始.例如

As mentioned at the start, the setup in these tests takes 95% of the test time so ideally I would like to run these as a series of steps together rather than starting from fresh for each feature. e.g.

• 设置一次
• 创建新消息
• 编辑消息
• 取消消息

是否可以将方案或功能链接在一起并重用上一个方案的系统状态?

Is it possible to chain the scenarios or features together and reuse the system state from the previous one?

还是我每次都必须从头开始启动系统?

Or do I have to start the system from scratch each time?

步骤定义是调用构成编辑"功能的所有其他步骤/方法的正确方法，是取消操作，还是应该编写很多And语句?

Is a step definition that calls all the other steps/methods that make up the Edit feature the right way to go for the Cancel or should I write lots of And statements?

推荐答案

我可以理解您对此的不满，但无法将后续功能相互构建.每个方案都是原子的和可重复的.方案彼此依赖的问题是失败的方案，将在随后的方案中导致级联失败.应用程序中的一个失败会触发多个失败的测试，从而使您的团队开始认为测试是易燃的.

I can understand your frustrations with this, but there is no way to have subsequent features build on each other. Each scenario is meant to be atomic and repeatable. The problem with scenarios depending on each other is a failed scenario will cause cascading failures in the scenarios that follow. One failure in the application triggers multiple failed tests, causing your team to start thinking the tests are flakey.

编写模拟先前场景的步骤没有错–mdash;这是正确的方法.在定义这些步骤时，请尽可能使它们原子化，以便于组合.

There is nothing wrong with writing a step that simulates the previous scenarios — this is the right way to do it. When defining those steps, keep them as atomic as possible so they are very composable.

说实话，一个6步方案就很好了.我建议的唯一更改是制作步骤的 Given 版本.取消方案在许多何时的情况下似乎都是必需的.

To be honest, a 6 step scenario is perfectly fine. The only change I would suggest is making Given versions of your steps. The cancel scenario looks like it has to many When's.

Feature: Cancelling a message

  Scenario: A User cancels a message
    Given there is a user called User1
    And there is a user called User2
    And User1 created a new message with id 1234
    And User2 added the location US to the message
    When User1 cancels the message
    Then User2 should see status Cancelled

这篇关于如何编写以先前功能为基础的黄瓜测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！