Improving Reliability with Testing Tools

Now that we can actually write and build our code for the browser efficiently, it makes sense to also consider verifying the code’s output. Does it really fulfill the given requirements? Has anything changed in terms of the expected outcome? Does the code crash when unexpected values are passed in?

What we need to answer these questions is testing. Testing can mean a lot of things – and depending on who you ask, you’ll get a different answer to the question “What should we test?” In this chapter, we’ll walk through the different options that interest us as developers. We’ll see what tools exist to automate these tests and how we can set them up and use them practically.

We will start our journey into the testing space with a discussion on the beloved testing pyramid. We will then continue by learning about the types of test tools – most notably, pure runners and whole frameworks....

Technical requirements

The complete source code for this chapter is available at https://github.com/PacktPublishing/Modern-Frontend-Development-with-Node.js/tree/main/Chapter07.

The CiA videos for this chapter can be accessed at https://bit.ly/3DW9yoV.

Considering the testing pyramid

Over the years, more and more types of software testing have been identified and added to the standard repertoire of software projects and testing professionals such as quality assurance engineers. A powerful tool to categorize and order the most common types of software testing is the testing pyramid.

The testing pyramid arranges the different types of testing by their visibility and effort. Higher layers of the pyramid require more effort but have greater visibility. Tests that are placed in the lower layers of the pyramid should be written a lot more – after all, these are the foundations of the pyramid.

An illustration of the testing pyramid is shown in Figure 7.1. The basis of the testing pyramid is formed by unit tests, which provide enough reliability to run components and integration tests on top of them later. Finally, UI tests (quite often referred to as end-to-end tests) can be run to verify that the solution works for end users...

Comparing test runners versus frameworks

Historically, tests for JavaScript targeting web browsers could not be just written and run automatically. The main reason was that this involved dealing with a real browser. There was no way to just pretend to run in the browser. For this reason alone, the first tools in that space have either been scripts or whole websites evaluating JavaScript or browser automation tools. The latter actually forms its own category – being at the heart of modern end-to-end tests.

The main driver for running the tests – historically, for starting everything that needs to be running to actually perform tests – is called a test runner. One of the first very successful test runners in the JavaScript space was Karma. The job of Karma was to spin up a server that runs a website hosting the tests, which are targeting JavaScript code that should run in a browser. Karma then opened available browsers to access the hosted website running the...

Using the Jest framework

Jest is a modern test framework that was authored by Facebook to fully leverage Node.js for running tests. It should have the power to run all the tests required at Facebook without requiring a diploma in engineering to understand, control, or modify it.

To use Jest, you need to install the jest package from npm:

$ npm install jest --save-dev

This allows you to use the jest command-line utility. Ideally, run it with npx as we did with the other tools:

$ npx jest

Jest can be configured by providing a jest.config.js file. The easiest way to create this kind of file is by using the jest tool with the --init flag. This will guide us through some questions to create a suitable configuration:

$ npx jest --init

The following questions will help Jest to create a suitable configuration for your project

 Would you like to use Jest when running "test" script in "package.json"? … yes

 Would you like to use Typescript for...

Using the Mocha framework

Mocha is an older but feature-rich testing framework that runs in Node.js and also the browser. In this section, we’ll exclusively use Mocha in Node.js. Unlike Jest, the notion of an environment does not exist. Nevertheless, a similar setup can be achieved, where browser APIs would be emulated by some npm package such as jsdom.

To use Mocha, you need to install the mocha package from npm:

$ npm install mocha --save-dev

This allows you to use the mocha command-line utility. Ideally, run it with npx as we did with the other tools:

$ npx mocha

At this point, not much is working. By default, Mocha follows a different convention from Jest. Here, we need to specify a different pattern or place our tests in a folder named test.

What we definitely need to do is to include Babel for code transformations. This works a bit differently than with Jest. Instead of a dedicated plugin, we only integrate the @babel/register package, which will automatically...

Using the AVA test runner

AVA is a modern test runner for Node.js. It stands out because of its ability to embrace new JavaScript language features and cutting-edge properties of Node.js, such as process isolation. In this way, AVA executes tests very quickly and reliably.

To use AVA, you need to install the ava package from npm:

$ npm install ava --save-dev

This allows you to use the ava command-line utility. Ideally, run it with npx as we did with the other tools:

$ npx ava

While Mocha and Jest could also be installed globally, AVA only works in projects as a local dependency. As this is the better setup anyway, there should be no practical downside from this constraint.

As mentioned, AVA is built quite closely on Node.js – following its conventions and rules wherever possible. In this regard, AVA also allows us quite quickly to adapt ESM instead of CommonJS. By modifying package.json for the project, we get immediate support for using ESM in our tests, too...

Using Playwright for visual tests

Node.js is not only a great basis for running logical tests but also for verifying visuals, such as those of a website running in a browser. A modern approach for browser automation is Playwright.

To use Playwright, you need to install the playwright package from npm:

$ npm install playwright --save-dev

The playwright package enables you to use Playwright in an existing application, which could also be inside existing tests such as unit tests executed with Jest using the jest-playwright-preset package.

An even better setup can be achieved by using the @playwright/test test runner package:

$ npm install @playwright/test --save-dev

This allows you to use the playwright command-line utility. Ideally, run it with npx as we did with the other tools:

$ npx playwright test

Running this will look for all files matching the same conventions as previously noted in the Jest and AVA sections. Every file ending with .test.js or .spec.js...

Using Cypress for end-to-end testing

Cypress is a focused, end-to-end testing framework that also comes with the ability to test individual UI components. It tries to be different by mostly avoiding browser automation. Instead, its test runner is located directly inside the browser.

To use Cypress, you need to install the cypress package from npm:

$ npm install cypress --save-dev

This allows you to use the cypress command-line utility. Ideally, run it with npx as we did with the other tools:

$ npx cypress open

Cypress is at its heart a graphical tool. As such, we are first introduced to a small configurator that allows us to set up our project. The configurator is shown in Figure 7.2. Picking E2E Testing will give you the ability to influence what files are written:

Figure 7.2 – The Cypress configurator on opening it for the first time

The configurator also lets you pick a browser where the tests should actually be run. Right now, Chrome...

Summary

In this chapter, you learned about which different types of testing we can automate and how important these types are for software projects to succeed. You’ve seen the popular tools that exist to help us cover our projects. By following the testing pyramid, you should be able to decide what tests you need to focus on to make your project as reliable as possible.

By using the power test frameworks such as Jest or Mocha or a flexible runner such as AVA, you can automate a lot of different things – from unit tests to full end-to-end tests. Dedicated end-to-end test frameworks such as Playwright or Cypress also come with their own runners – which makes sense for complex visual tests in particular. In the unit and integration testing space, Jest comes in handy. It also allows us to quickly integrate other flavors of JavaScript or customize a lot of different features.

In the next chapter, we will finally also publish our own packages – to the public...