Chapter 15. E2E Testing in React

For our backend development, we vehemently followed Test-Driven Development (TDD) – we started development by writing E2E tests, and we wrote some implementation code to make these tests pass. After we implemented this feature, we added unit and integration tests to add more confidence to our underlying code, and also to help catch regression.

Now that we have a basic understanding of React, we will, in this chapter, examine how we can implement TDD in React. Specifically, we will cover:

• Using Selenium to automate interaction with the browser
• Working with React Router to implement client-side routing

Testing strategies

As it turns out, TDD on the frontend follows a similar approach involving automated UI testing and Unit tests.

Automated UI testing

When we write E2E tests for our API, we first compose our request, send it, and assert that it returns what is expected. In other words, our E2E tests are mimicking how an end user would interact with our API. For the frontend, a user would interact with our application through the user interface (UI). Therefore, the equivalent to E2E testing would be automated UI testing.

UI tests automate the actions that a user of the application would take. For example, if we want to test that an user can register, we'd write a test that:

• Navigates to the /register page
• Types in the email
• Types in the password
• Presses the Register button
• Asserts that the user is registered

These tests can be written in Gherkin and run with Cucumber. The actual mimicking of the user action can automate these using Browser Automation Tools like Selenium. For example, when we run...

Writing E2E tests with Gherkin, Cucumber, and Selenium

Now, we are ready to integrate with tools that can mimic user interaction with a browser. For our first test, let's test something very simple—a user will type in a valid email, but their password is too short. In this case, we want to assert that the Register button will be disabled.

Like our backend E2E tests, we will be writing our test cases in Gherkin, and using Cucumber to run our scenarios. So, let's add these as development dependencies:

$ yarn add cucumber babel-register --dev

Then, we need to create feature files and step definition files. For our first scenario, I have opted to group the features and steps in the following structure:

$ tree --dirsfirst spec
spec
└── cucumber
    ├── features
    │   └── users
    │       └── register
    │           └── main.feature
    └── steps
        ├── assertions
        │   └── index.js
        ├── interactions
        │   ├── input.js
        │   └── navigation.js
        └── index.js

Note...

Routing with React Router

Next, we will develop the Login page. This requires us to use a different path for each page. For instance, the Register page can be served under the path /register, and the Login page under the /login path. For this, we need a router. On the server, we use Express to route the request hitting our API; for the frontend, we need a client-side router to do the same. In the React ecosystem, the most mature router is React Router. Let's install it:

$ yarn add react-router react-router-dom

react-router provides the core functionality, and react-router-dom allows us to use the React Router on the web. It's similar to how React on the web is split into react and react-dom.

Basics

As explained previously, everything in React is a component. React Router is no different. React Router provides a set of navigational components that'll collect data from the URL, viewport, and device information, in order to display the appropriate component.

There are three types of components in...

TDD

When we developed the Register page, we implemented the features before writing the test. We did this because we didn't know how E2E tests work with React. Now that we do, it's time to implement a proper TDD process.

To implement TDD, we should look at the design of the UI, identify key elements that our tests would need interact with, and assign each of them an unique id. These ids then form the contract between our tests and the implementation.

For instance, if we developed our Registration Page using TDD, we would first assign the inputs to the IDs #email, #password, and #register-button, and write our test code using these IDs to select the element. Then, when we implement the feature, we will make sure to use the same IDs as specified in the test.

By using an id field, we can change the implementation details but leave the tests untouched. Imagine if we used a different selector, say, form > input[name="email"]; then, if we add an inner wrapper within the <form> element, we...

Over to you

We have already gone over how to write E2E tests in a previous chapter, and we have demonstrated how to apply TDD for our Register and Login pages.

Now, we pass the baton to you so that you can improve on what we've done so that it conforms to the design, as well as complete the rest of the app in a TDD manner.

Note

You don't need to focus on making things look pretty – that's not the focus here. Just make sure that all of the components are there and that the user flow is correct.

After you've done this, take a look at our implementation and use it to improve yours. Then, we'll take a look at unit tests and other types of testing that can be applied to front-end code.

Summary

In this chapter, we have carried over what we did for our back-end API to the front-end code. We used Cucumber, Gherkin and Selenium to compose UI tests that runs directly on a real browser. We also implemented client-side routing using React Router.

In the next chapter, we will round off our excursion into the front-end world by learning about Redux, a powerful state management library.