Writing Your First Cucumber Test

Test-driven development is primarily a process for developers. Sometimes, customers and product owners want to see the results of automated tests too. Unfortunately, the humble unit test that is the foundation of TDD is simply too low-level to be helpful to non-developers. That’s where the idea of Behavior Driven Development (BDD) comes in.

BDD tests have a few characteristics that set them apart from the unit tests you’ve seen so far:

• They are end-to-end tests that operate across the entire system.
• They are written in natural language rather than code, which is understandable by non-coders and coders alike.
• They avoid making references to internal mechanics, instead focusing on the outward behavior of the system.
• The test definition describes itself (with unit tests, you need to write a test description that matches the code).
• The syntax is designed to ensure that your tests are written as examples, and as discrete...

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/Chapter17

Integrating Cucumber and Puppeteer into your code base

Let’s add the necessary packages to our project:

1. Start by installing the packages we’re after. As well as Cucumber and Puppeteer, we’ll also pull in @babel/register, which will enable us to use ES6 features within our support files:

   $ npm install --save-dev @cucumber/cucumber puppeteer 
   $ npm install --save-dev @babel/register

2. Next, create a new file named cucumber.json with the following content. This has two settings; publishQuiet turns off a bunch of noise that would otherwise appear when you run tests, and requireModule hooks up @babel/register before tests are run:

   {
     "default": {
       "publishQuiet": true,
       "requireModule": [
         "@babel/register"
       ]
     }
   }

3. Create a new folder called features. This should live at the same level as src...

Writing your first Cucumber test

In this section, you’ll build a Cucumber feature file for a part of the Spec Logo application that we’ve already built.

Warning on Gherkin code samples

If you’re reading an electronic version of this book, be careful when copying and pasting feature definitions. You may find extra line breaks are inserted into your code that Cucumber won’t recognise. Before running your tests, please look through your pasted code snippets and remove any line breaks that shouldn’t be there.

Let’s get started!

1. Before running any Cucumber tests, it’s important to ensure that your build output is up to date by running npm run build. Your Cucumber specs are going to run against the code built in the dist directory, not your source in the src directory.

Use package.json scripts to your advantage

You could also modify your package.json scripts to invoke a build before Cucumber specs are run, or to...

Using data tables to perform setup

In this section, we’ll look at a useful time-saving feature of Cucumber: data tables. We’ll write a second scenario that, as with the previous one, will already pass given the existing implementation of Spec Logo:

1. Create a new feature file called features/drawing.feature with the following content. It contains a set of instructions to draw a square using a Logo function. A small side length of 10 is used; that’s to make sure the animation finishes quickly:

   Feature: Drawing
     A user can draw shapes by entering commands
     at the prompt.
     Scenario: Drawing functions
       Given the user navigated to the application page
       When the user enters the following instructions at the prompt:
         | to drawsquare |
         |   repeat 4 [ forward 10 right 90 ] |
        ...

Summary

Cucumber tests (and BDD tests in general) are similar to the unit tests we’ve been writing in the rest of the book. They are focused on specifying examples of behavior. They should make use of real data and numbers as means to test a general concept, like we’ve done in the two examples in this chapter.

BDD tests differ from unit tests in that they are system tests (having a much broader test surface area) and they are written in natural language.

Just as with unit tests, it’s important to find ways to simplify the code when writing BDD tests. The number one rule is to try to write generic Given, When, and Then phrases that can be reused across classes and extracted out of step definition files, either into the World class or some other module. We’ve seen an example of how to do that in this chapter.

In the next chapter, we’ll use a BDD test to drive the implementation of a new feature in Spec Logo.