如何编写基于先前功能的 Cucumber 测试？

Question

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.

One business flow is:

• User1 saves a new message
• User2 edits the message
• User1 verifies the edit
• User1 cancels the message
• User2 acknowledges cancellation

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

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

New

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

Edit

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:

Cancel

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

I could write the Cancel like this instead:

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

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.

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. eg

• Do the setup once
• Create a New message
• Edit the message
• Cancel a message

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?

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?

Answer 1

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.

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.

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

Answer 2

Original : You could pull the code out of each of the setup steps and make them functions, call the functions as the code to the steps (performing the same tasks as before), and create a new setup step calling those functions, which would mean they'd have a shared implementation

Alternative : write a tagged Before hook that knows the state of the system under test , even if it is just whether the setup step has occurred, and use that information to reset the system for those scenarios. You could even perform health checks here to ensure that a full reset can happen if the system needs it.

Or even put this code into the steps themselves, and let them know to skip sections if the health checks have passed (most likely an if statement)