What Cypress is, and where it fits

Cypress is a tool that opens a web browser and performs the same actions a person would: clicking buttons, typing into forms, and reading what appears on the screen.

The difference is that it does this in a few seconds, and it does exactly the same thing every time.

Here is the problem it solves.

Say your site has a login page. You check it by hand. The correct password works. The wrong password shows an error. It works, so you move on.

Two weeks later, someone edits a piece of code that the login page shares with another screen. Login quietly breaks. Nobody checks it, because login already worked. A customer finds it on Monday morning.

Instead of repeating these checks by hand after every change, Cypress lets you describe them in code. The check is written once, and runs automatically from then on.

What a test looks like

it('shows an error when the password is wrong', () => {
  cy.visit('/login');
  cy.get('[data-testid="email"]').type('demo@example.com');
  cy.get('[data-testid="password"]').type('wrong-password');
  cy.get('[data-testid="submit"]').click();
  cy.get('[data-testid="error"]').should('contain', 'Incorrect password');
});

Read it from top to bottom. It is close to English.

• it(...) is one test. The sentence inside is what you say the app should do.
• cy.visit opens a page.
• cy.get points at an element, meaning one thing on the page such as a button or a text box. The part inside the brackets describes which one you mean. Lecture 5 covers how to write those well.
• .type and .click do what a user does.
• .should is the check.

That last line is the important one. Without it, the test clicks through the page and proves nothing.

A test is steps plus a check. The steps make something happen. The check decides whether it was right.

Where Cypress fits

Cypress interacts with your application through a browser, performing the same types of actions users perform: clicking, typing, and checking results.

This is called end-to-end testing, because it checks a complete user journey through your application, from the user's actions in the browser to the expected result.

Other kinds of tests exist. A unit test checks one function on its own, with no browser. Unit tests are faster and narrower. End-to-end tests are slower and closer to real life, so teams write a small number of them, covering the journeys that matter most, like signing in and paying.

Cypress also handles many timing problems automatically, so you will not need to add manual pauses to your tests. Lecture 9 covers how that works.

Cypress is one of three tools you will see in job postings for this work. The others are Playwright and Selenium. They solve the same problem in different ways, and this site teaches all three.

One honest thing before you start

An automated test does not find new bugs. It cannot look at a screen and decide that the wording is confusing.

What it does is notice when something that used to work stops working. That is most of the value, and it is why a test written in March still earns its place in September.

Remember this: Cypress drives a real browser through your app, and the check at the end is what makes it a test.

Next: the apps you will practise on.

Reference: Why Cypress?