#100DaysOfCode: Day 6

Cypress in Action

Yesterday I spoke a little about Cypress. Today I want to take some time to talk more about testing with Cypress and how we deployed it inside the project we are currently working on.

Cypress is a third-party npm module we use for End-to-end testing. End-to-end testing involves testing the entire application. We want to test everything including the client, API, database, and other services. This type of testing gets the application ready for production.

Writing Tests with Cypress: Starting simple

Let’s take a look at what writing tests with Cypress

Cypress’ library contains a lot of keywords we can use to accomplish our goals. You can read about these keywords here (https://docs.cypress.io/guides/overview/why-cypress.

This is our very first test within our Cypress test file. Since our app works off the localhost:3000 port, we added a beforeEach hook at the start to the test to dry the code and avoid repeating this line before every single test.

At first glance, we can see the syntax of this test is very similar to unit testing. It begins with an it statement. The first parameter takes in a string as an argument that explains the goal we are attempting to test. The second parameter takes in an arrow function that contains the following tests we want to perform.

Cy is the keyword we use when we want to access the Cypress library. .get() is a Cypress keyword that will search the page for a JSX tag that matches the string given in the argument. In this case, we are searching for a <header> tag that exists at the very top of our app. Contains() is another cypress keyword that will search the JSX tag we just retrieved from the.get() command for a string that includes ‘Rancid Tomatillos’. So in this case we are testing if the header element containing “Rncid Tomatillos” appears on the page for a user. Testing for a header element may not be the best way to test if your application loads but for us, it works just fine. Maybe we want to test for more than a header? Let’s dive deeper.

Diving Deeper

With Cypress, we can also test individual buttons on the page. Before we added React Router to our project, we needed a way for the user to return to the home page after they have viewed a movie. So we created one single Button element on each page that handles this functionality. In this test we first navigate to a single movie page.. On the next line we ask for Cypress to look for a button element. The next line, number 22, asks Cypress to perform a click on the button. We then need to evaluate where the user has been taken after the button click. We use .url().should() to check which url the user has arrived at. If the user arrives back at localhost/3000, the test will be a success.

The day after we wrote the test above we implemented React Router into our project. React Router allows a single-page website to mimic the functionality of a multipage website. This means the user now has access to the forward and back buttons within the browser like they would on a live web application.

We can also use Cypress to test if we implemented Router successfully in our project. This test is very similar to the one above with one exception. Instead of looking for an individual element with .get(), we can use the Cypress keyword .go() to target these back and forward buttons. Then we follow up with url() and should() to confirm the user is where they need to be.

This is just scratching the surface of testing with Router. I am looking forward to exploring more with this technology. That’s all for today!