Cypress.io And End-To-End Testing - What You Need To Know

End-to-end testing is another tool in our tool belt as developers to confirm our app works for users the way it's intended to. And Cypress.io is a simple, intuitive, incredibly powerful, and rapidly improving framework that makes the process of writing and running end-to-end tests much less of a pain than it used to be.

In this lesson, we'll talk about the purpose of end-to-end testing and how Cypress is different (and better) than all the e2e testing libraries that have come before it.

End-to-end tests#

In case you're less familiar with end-to-end testing and its purpose — especially when integration tests are already present in an application — let's talk a little about it.

What are end-to-end tests? What unique problems do they solve?

End-to-end testing is the process of testing software from start to finish as it will be used by the actual users.

While unit and integration tests can test small pieces of the app (often with mocked data), e2es can (sometimes) test against real databases, configurations, and external dependencies outside of the control of your application — things that could certainly influence an app's functionality but wouldn't necessarily be covered in other types of tests.

Additionally, e2es can test that everything in the UI is present and in the right place. They can determine if elements a user wants to interact with are visible or hidden, enabled or disabled, look and act the way they're supposed to, and give a pleasant user experience.

End-to-end tests serve as another layer of protection for developers that the whole application works as expected.

As far as e2e testing goes, it's recommended that e2es test the mission-critical flows in an app — the flows that, if they don't work with an automated user, indicate they most likely won't work for a real user and need to be reviewed.

The "testing trophy" strategy

If you've been doing web development for a while, you may be familiar with the testing pyramid, which has been in fashion since being displayed at the Google 2014 keynote.

The thinking with the test pyramid is like this: most tests should be unit tests, followed by a smaller set of integration tests, and finally topped off with a few end-to-end tests. A "pyramid" of tests.

Lately, however, there's a new shape that's catching on — especially when it comes to frontend framework testing: the testing trophy, a term coined by Kent C. Dodds and inspired by Guillermo Rauch.

The trophy still has e2e tests as the smallest amount of tests, but it prioritizes more integration tests than unit tests and adds static tests to catch typos and type errors.

This sounds pretty good in theory, but let's talk about how we might put it into practice: concrete examples help some (myself included) understand things better.

A test plan for e2es