Cypress Explained: Testing Websites the Way Users Use Them

Introduction

Jest tests individual functions. But users don't use functions — they use websites: they click buttons, fill in forms, and expect the right page to appear. Cypress tests that whole experience by driving a real browser: it loads your site, performs actions exactly as a user would, and checks what actually appears on screen.

Your first end-to-end test

A Cypress test reads like a user story:

describe("Login page", () => {
  it("lets a user sign in", () => {
    cy.visit("/login");
    cy.get("input[name=email]").type("sara@example.com");
    cy.get("input[name=password]").type("secret123");
    cy.get("button[type=submit]").click();
    cy.contains("Welcome back, Sara").should("be.visible");
  });
});

cy.visit loads the page, cy.get finds elements, .type and .click act on them, and should("be.visible") asserts the result. Cypress automatically waits for elements to appear instead of making you guess sleep durations, and when a test fails it shows exactly what the page looked like at that moment — a screenshot and a replayable command log, not just a stack trace.

Selectors: the test's weak point

The most common Cypress mistake is fragile selectors: tests that break every time a designer changes a class name. The fix is test-specific attributes that designers never touch for styling:

<button data-cy="submit-login">Sign in</button>
cy.get("[data-cy=submit-login]").click();

Now the test survives redesigns, because data-cy exists for tests alone. A test suite that breaks on every cosmetic change gets ignored; one that only breaks when behaviour changes gets trusted.

The honest trade

End-to-end tests are slower and flakier than unit tests — browsers, networks, and timing all introduce variables — so Cypress is not a replacement for Jest. The standard shape is a pyramid: many fast unit tests, fewer integration tests, and a small number of Cypress tests covering the critical user journeys (sign up, check out, pay). Run the full Cypress suite on every commit and it becomes a bottleneck; run it on the journeys that must never break, and it becomes a safety net.

Takeaway

Cypress proves the whole website works the way a user experiences it, automatic waiting and visual failure reports make failures debuggable, and stable data-cy selectors keep tests trustworthy. Use it for the journeys that matter most — not for everything.

Comments

Post a Comment

Popular posts from this blog

Swift Explained: Apple's Language for iPhone, Mac, and More

Introduction Swift is Apple's language for its platforms: iPhone, iPad, Mac, Apple Watch, and Apple TV. Introduced in 2014 to replace the older Objective-C, it was designed to be safe, fast, and — unusually for a systems language — genuinely pleasant to read and write. Even if you never ship an app, Swift teaches one idea every developer should understand: optionals. Optionals: saying "this might be missing" Most bugs in app development come from one cause: code assuming a value exists when it does not. Swift makes that assumption impossible to hide. A value that might be missing is wrapped in an Optional, and you must unwrap it before use. var nickname: String? = nil nickname = "Waqas" if let name = nickname { print("Hello, \(name)!") } else { print("No nickname set.") } String? means "a String, or nothing". The if let unwraps it safely: inside the block, name is guaranteed to exist. There is no way to accidentally us...
Read more

Flutter Explained: One Codebase, Every Screen

Introduction Flutter is Google's framework for building apps from a single codebase: write once in Dart, and ship to iOS, Android, web, Windows, macOS, and Linux. It powers apps from Google Pay to the New York Times crossword app. Its core idea is simple and radical: everything on screen is a widget, and the interface is rebuilt from data whenever that data changes. Everything is a widget In Flutter, there are no separate concepts for layout, styling, and controls — everything is a widget, nested inside other widgets like HTML elements, but in code: import 'package:flutter/material.dart'; class Greeting extends StatelessWidget { @override Widget build(BuildContext context) { return Center( child: Text( 'Hello, Sara!', style: TextStyle(fontSize: 24, color: Colors.teal), ), ); } } Center positions its child, Text displays words, TextStyle styles them — each a widget, composed by nesting. Layout widgets (like Row, Column, ...
Read more

Go Explained: Simple Code That Runs Fast

Introduction Go was built at Google for a specific frustration: large programs that were slow to build and hard to read. The answer was a language that is deliberately small — fewer features, but the right ones, done well. If you know one programming language already, Go will feel familiar within an hour. The interesting parts are not the syntax, but two ideas: goroutines and channels. Goroutines: cheap concurrency Most languages make running things at the same time feel heavy — threads, thread pools, and careful setup. A goroutine is Go's lightweight version: you start one by writing go in front of a function call. package main import ( "fmt" "time" ) func say(text string) { for i := 0; i < 3; i++ { fmt.Println(text) time.Sleep(100 * time.Millisecond) } } func main() { go say("hello") say("world") time.Sleep(500 * time.Millisecond) } The go say("hello") line does not wait — it st...
Read more