Add Cypress To A React App For Automated End-To-End Testing

[00:00 - 00:12] 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.

[00:13 - 00:30] This lesson will focus on adding Cypress to our React application and config uring it to run tests, both in headless and headed mode, depending on the need. Need a fresh copy of the sample app before we begin our end-to-end testing? You can download it here in the lesson.

[00:31 - 00:44] 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 into your own app.

[00:45 - 01:02] We're going to do inside of our client folder, YarnAddCypress-dev. The first time that you install it, it will take a minute. There's a lot of good info, demos, and configurations that come along with the Cypress install, so be patient.

[01:03 - 01:15] When it's done successfully, you'll see the new Cypress library in your package JSON. So now, once it is installed, we see Cypress right here. Very good.

[01:16 - 01:28] So after the initial install is done, we're going to make sure that it worked. In your terminal inside of the client folder, type the following command. Yarn RunCypress-open.

[01:29 - 01:44] 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 it will look something like this.

[01:45 - 02:03] We have all sorts of integration tests, some getting started things, and then some advanced examples. Lots of them. A nice new inclusion in addition to the Cypress test runner itself is a whole suite of predefined tests showing you how to do various different types of testing with Cypress.

[02:04 - 02:15] And I want to recommend that you don't discount these sample files. This wasn't available when I first started using Cypress, but luckily the documentation and the examples have been good since the start.

[02:16 - 02:28] But if you were ever wondering how to do something and wanted a quick reference in actual tests that you can modify, these samples are very helpful. So if you'd like to see the test runner in action, go ahead and click the Run button.

[02:29 - 02:41] This is going to kick off all the pre-configured 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.

[02:42 - 02:51] So let's run this now. Here is an example of a Cypress test running.

[02:52 - 03:02] It went through it super quickly, but that is exactly what it does. It opens up a browser and it runs through all the things that you tell it to. We'll get into this in more detail soon.

[03:03 - 03:08] For now, go ahead and click Stop. And we are going to do a little bit of setup for ourselves.

[03:09 - 03:20] So you can go ahead and close out of this for now. And 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.

[03:21 - 03:27] And debugging. And to run Cypress in headless mode, the same way it would run in a CI build pipeline.

[03:28 - 03:41] Inside of our client folders package JSON, add the following two commands to our scripts section. We are going to add Cypress open.

[03:42 - 03:49] And the command for that will just be Cypress open. And we are going to run to add Cypress run.

[03:50 - 03:57] The command for that, which is Cypress run. Pretty straightforward.

[03:58 - 04:08] Let's talk a little bit about these two different scripts that we've just written. So our first new script of Cypress open does just what we did manually from the command line a section ago.

[04:09 - 04:21] 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.

[04:22 - 04:45] 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. The second script, Cypress run, runs Cypress in headless mode.

[04:46 - 04:57] 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 set it up as a build step in a continuous integration pipeline.

[04:58 - 05:08] Typically, there should be very little difference between a run in the visible test runner and a headless run here. For debugging purposes, it's useful to have both commands within easy access.

[05:09 - 05:24] If you'd like, we can test out our new scripts now. Inside of the client folder in the terminal, run the following command, Yarn, Cypress Open.

[05:25 - 05:42] And at this point, the test runner should show up in a new browser window, so you can go ahead and close this one down again. And in the terminal, once again, issue our other command, Yarn, Cypress, run.

[05:43 - 05:58] And with this command, nothing much should change visibly, but you should start to see E2E tests begin to print out in the console as the tests run in headless mode. And if I open the console up a little wider, you'll see them start to scroll across.

[05:59 - 06:10] Once all the tests have run, you'll see this nice formatted printout in the terminal, clearly showing what tests suites past and failed. Good. Everything seems to be in order.

[06:11 - 06:21] Cypress is downloaded, our scripts to run it are set up and working. So let's take a few moments to look at the new folder structure that Cypress has added to our project for our E2E tests.

[06:22 - 06:31] If you check our client folder now, you'll notice some new additions to it. You should see a new Cypress folder and a Cypress.json file at the root of the folder.

[06:32 - 06:41] Both of these were generated by Cypress when it was installed. And if you expand the Cypress folder in your IDE, you'll see a bunch of folders nested inside of it.

[06:42 - 06:52] Vixtures, integrations, plugins, support, screenshot, videos, etc. There's a couple of other folders in here also, but the contents of those are generated when the tests run.

[06:53 - 07:02] They contain video recordings of tests run and screenshots of failing tests, or when the "side.screenshot" command is called. We'll add these folders to our gitignore file shortly.

[07:03 - 07:08] The folders to focus on, however, are the first four that I mentioned. We'll talk a little bit about what they do.

[07:09 - 07:18] The integrations folder is where our tests are going to live. It's also the default folder that Cypress will look in for test files unless we specify differently.

[07:19 - 07:39] You can think of them as very similar to any of our integration test files, except instead of being named xyz.test.js, they'll have naming conventions like xyz_spec.js. Vixtures is up next.

[07:40 - 07:48] Test data goes inside of our fixtures folder. It's where our mocked data to supply to tests, usually for responses from network requests, is stored.

[07:49 - 07:59] The equivalent of this folder is our "mox" folder that supplies data for our integration tests. These also are JSON files, just like in our "mox" folder.

[08:00 - 08:10] Next up is plugins. Plugins contains a special file that executes in Node before a project is loaded, before the browser launches, and during your test execution.

[08:11 - 08:29] While the Cypress tests execute in the browser, the plugins file runs in the background Node process, giving tests the ability to access the file system and the rest of the operating system. I have never used this folder in my own development, but it's worth noting that it's there.

[08:30 - 08:36] And finally, support. The file inside of the support folder runs before every single spec file.

[08:37 - 08:55] The support folder is a great place to put reusable behavior, such as custom commands or global overrides, that we want applied and available to all of our spec files. Examples of this might include a login sequence that's needed at the beginning of every test or mocked data that the site needs to know from the beginning, like feature flags.

[08:56 - 09:03] This is also the folder where I like to keep REST API mox. You'll see what I mean when we get to writing tests for our own application.

[09:04 - 09:09] Okay, we've talked about the most important folders. Let's move on and do a little bit more project config now.

[09:10 - 09:21] And I am going to minimize this terminal so it's easy to see what we're doing. So as I said earlier, there are a few generated folders when our Cypress tests run that will want to add to our gitignore file.

[09:22 - 09:28] We don't need to commit them to our repo and GitHub. The folders that I'd recommend adding are the screenshots and the videos folders.

[09:29 - 09:45] So let's go ahead and open up our gitignore file and add the following two lines, on line 15 and 16. We are going to call these E2E test output files.

[09:46 - 09:53] And the first one is going to be Cypress screenshots. And the second one is going to be Cypress videos.

[09:54 - 09:57] We save that. Those two instantly become gray.

[09:58 - 10:07] So that should take care of those files being added to our remote repo. Now, you didn't think that we'd get through this lesson without adding at least one more linting file, did you?

[10:08 - 10:14] Of course not. Naturally, Cypress has its own set of ES linters and we're going to add them to our project.

[10:15 - 10:39] First, we're going to need to install two new libraries, the ES lint plugin Cyp ress library, and the ES lint plugin chai-friendly library. The ES lint plugin Cypress library is a library that has rules that enforce some of the recommended best practices for using Cypress, just like how the rest of our ES lint files enforce good react coding standards in our application.

[10:40 - 11:03] The second library we're adding, ES lint plugin chai-friendly, overrides the no unused expressions ES lint error to make it friendly towards chai, where expect and should statements are the common way of asserting things. It will eliminate our need to add in-line ignore statements in our tests, like where we ES lint disable different various things, like unused expressions.

[11:04 - 11:11] So open up a terminal, if you haven't already. CD into your client folder and run the following commands.

[11:12 - 11:36] First, we will do yarn add ES lint plugin - Cypress - saved of. And then we will run yarn add ES lint - plugin - chai-friendly - - dev.

[11:37 - 11:49] Once they're added to our project as dependencies, we will enable them by adding a new ES lint RC.json file, which we'll create. And we can see that they have been added right here.

[11:50 - 12:03] We're ready to go. So inside of the Cypress folder, we are going to go and create a new file and name it ES lint.es lint RC.json.

[12:04 - 12:31] And in the ES lint RC.json file, we're going to add the following lines. We're going to say extends and then make an array and we will say plugin colon Cypress/recommended, comma, plugin colon chai-friendly - recommended, flash recommended.

[12:32 - 12:34] And we're done. Pretty simple, right?

[12:35 - 12:48] Last thing to do in this lesson is clean out our Cypress folder so that we've got a clean slate to write our own tests on in the next lesson. If you open up the Cypress test runner, there is an option to clear out all the tests. Go ahead and do so now.

[12:49 - 12:58] After that, delete the three files in the fixtures folder and we'll be ready to roll. So we are going to do yarn Cypress open.

[12:59 - 13:06] And once the test runner has opened up, we are going to delete our example files. Okay.

[13:07 - 13:08] Good. Save that.

[13:09 - 13:17] And then if we go up to our fixtures folder, we will get rid of all of these. Delete those.

[13:18 - 13:27] And with that, we are ready. In the next lesson, we'll talk through a couple of good e-to-e test flows for our application and then write them out just as we would for applications of any sort of application.

[13:28 - 13:29] applications of any size.