Set up End-to-End Tests
Cypress gives us a big helping hand organizing and getting started with our own e2es.
Set up automated end-to-end testing in Hardware Handler#
Like I was saying in the previous lesson, Cypress is really light years ahead of all the other end-to-end testing frameworks out there. And this even applies to its setup and integration into existing projects as well.
This lesson will focus on adding Cypress.io to our React application and configuring it to run tests — both in headless and headed mode, depending on the need.
Sample code zip file
Need a fresh copy of the sample app before we begin our end-to-end testing? You can download it here.
Install Cypress in our app#
We'll need to add Cypress as a dev dependency to Hardware Handler before we can start to take advantage of its capabilities.
So, open up a new terminal instance and run the following command to install Cypress.
The first time you install it, it will take a minute. There's a lot of good info, demos, and configuration that come along with the Cypress install, so be patient.
When it's done successfully, you'll see the new
"cypress" library in your
Verify Cypress works#
After the initial install is done, we'll make sure it worked.
In your terminal, inside of the
client/ folder, type the following command:
If everything goes according to plan, your terminal should recognize that this is the first time Cypress is fired up.
And after the welcome message, a new window containing the Cypress Test Runner should automatically open up and look something like this.
A nice, new inclusion in addition to the Cypress Test Runner itself is a whole suite of predefined tests showing how to do various different types of tests with Cypress.
Don't discount the example files
This wasn't available when I first started using Cypress, but luckily, the documentation and examples have been good since the start.
But if you were ever wondering how to do something and wanted a quick reference in actual tests you can modify, these samples are pretty helpful.
If you'd like to see the test runner in action, go ahead and click the Run button. This will kick off all the preconfigured tests and give you a taste of how Cypress operates.
A little later in this lesson, we'll go over all the various pieces of code that go into making these tests work and how they're organized.
With Cypress installed in our project, it's time to add a few scripts to our
package.json to make it easier to run Cypress in a browser that's visible to us for active development and debugging and to run Cypress in "headless" mode — the same way it would run for in a CI build pipelines.
Inside of our
package.json file, add the following two commands to our
Our first new script:
"cypress:open" does just what we did manually from the command line a section ago: it opens the Cypress test runner browser so that we can interact with our tests.
In addition to being able to debug and test code in the browser, this test runner lets us be very targeted and specific about which test suites we want to run.
For instance, if you're only adding tests to one particular suite (or know that the code you changed should only impact the functionality for one set of tests), you can select only those tests to run in the interactive test runner instead of waiting for them all to run (which is what happens by default in headless mode).
This script runs Cypress in headless mode. When it begins, all the tests will run, but we won't see anything on-screen besides what's being printed out in the terminal.
This is the command that would be run if we had it set up as a build step in a continuous integration (CI) pipeline.
Typically, there should be very little difference between a run in the visible test runner and a headless run here, but for debugging purposes, it's useful to have both commands within easy access.
If you'd like, we can test out our new scripts now.
client/ folder in the terminal, run the following command:
At this point, the test runner should open in a new browser window.
Go ahead and close this down. And in the terminal, once again, issue our other command: