Adding Features Guided by Cucumber Tests

In the last chapter, we studied the basic elements of writing Cucumber tests and how to use Puppeteer to manipulate our UI. But we haven’t yet explored how these techniques fit into the wider development process. In this chapter, we’ll implement a new application feature, but starting the process with Cucumber tests. These will act as acceptance tests that our (imaginary) product owner can use to determine whether the software works as required.

Acceptance testing

An acceptance test is a test that a product owner or customer can use to decide whether they accept the delivered software. If it passes, they accept the software. If it fails, the developers must go back and adjust their work.

We can use the term Acceptance-Test-Driven Development (ATDD) to refer to a testing workflow that the whole team can participate in. Think of it as like TDD but it is done at the wider team level, with the product owner and customer involved...

Technical requirements

The code files for this chapter can be found here:

https://github.com/PacktPublishing/Mastering-React-Test-Driven-Development-Second-Edition/tree/main/Chapter18

Adding Cucumber tests for a dialog box

In this section, we’ll add a new Cucumber test that won’t yet pass.

Let’s start by taking a look at the new feature:

1. Open the features/sharing.feature file and take a look at the first feature that you’ve been given. Read through the steps and try to understand what our product owner is describing. The test covers quite a lot of behavior—unlike our unit tests. It tells a complete story:

   Scenario: Presenter chooses to reset current state when sharing
     Given the presenter navigated to the application page
     And the presenter entered the following instructions at the prompt:
       | forward 10 |
       | right 90 |
     And the presenter clicked the button 'startSharing'
     When the presenter clicks the button 'reset'
     And the observer navigates to the presenter's sharing link
     Then the...

Fixing Cucumber tests by test-driving production code

In this section, we’ll start by doing a little up-front design, then we’ll write unit tests that cover the same functionality as the Cucumber tests, and then use those to build out the new implementation.

Let’s do a little up-front design:

• When the user clicks on Start sharing, a dialog should appear with a Reset button.
• If the user chooses to reset, the Redux store is sent a START_SHARING action with a new reset property that is set to true:

  { type: "START_SHARING", reset: true }

• If the user chooses to share their existing commands, then the START_SHARING action is sent with reset set to false:

  { type: "START_SHARING", reset: false }

• When the user clicks on Reset, a RESET action should be sent to the Redux store.
• Sharing should not be initiated until after the RESET action has occurred.

That’s all the up-front design we need. Let’s move on to...

Avoiding timeouts in test code

In this section, we’ll improve the speed at which our Cucumber tests run by replacing waitForTimeout calls with waitForSelector calls.

Many of our step definitions contain waits that pause our test script interaction with the browser while we wait for the animations to finish. Here’s an example from our tests, which waits for a period of 3 seconds:

await this.getPage("user").waitForTimeout(3000);

Not only will this timeout slow down the test suite, but this kind of wait is also brittle as there are likely to be occasions when the timeout is slightly too short and the animation hasn’t finished. In this case, the test will intermittently fail. Conversely, the wait period is actually quite long. As more tests are added, the timeouts add up and the test runs suddenly take forever to run.

Avoiding timeouts

Regardless of the type of automated test, it is a good idea to avoid timeouts in your test code. Timeouts...

Summary

In this chapter, we looked at how you can integrate Cucumber into your team’s workflow.

You saw some more ways that Cucumber tests differ from unit tests. You also learned how to avoid using timeouts to keep your test suites speedy.

We’re now finished with our exploration of the Spec Logo world.

In the final chapter of the book, we’ll look at how TDD compares to other developer processes.

Exercise

Remove as much duplication as possible from your step definitions.