First Cypress test - Deep Dive

Overview - First Cypress test

What is it?

A Cypress test is a small program that checks if a website or web app works as expected. It runs in a browser and simulates what a user does, like clicking buttons or typing text. The first Cypress test is the simplest example to show how to write and run these checks. It helps beginners see how testing with Cypress works in practice.

Why it matters

Without tests like these, developers might release websites with bugs that users find frustrating. The first Cypress test shows how easy it is to catch problems early by automatically checking the site. This saves time and makes websites more reliable. Without such tests, fixing bugs would be slower and costlier, hurting user trust.

Where it fits

Before learning Cypress tests, you should know basic web concepts like HTML and how browsers work. After this, you can learn more Cypress commands, how to test complex user flows, and how to organize many tests for bigger projects.

Mental Model

Core Idea

A Cypress test is like a robot user that opens a website, tries actions, and checks if everything looks right.

Think of it like...

Imagine you have a remote-controlled toy car. You press buttons to make it move and check if it goes where you want. Cypress is like that remote control, but for websites, pressing buttons and watching what happens.

┌───────────────┐
│ Start Browser │
└──────┬────────┘
       │ Opens website
       ▼
┌───────────────┐
│ Simulate User │
│  Actions     │
└──────┬────────┘
       │ Check results
       ▼
┌───────────────┐
│ Assert Output │
└───────────────┘

Build-Up - 6 Steps

1

Foundation

Setup Cypress and Open Test File

Concept: Learn how to install Cypress and create the first test file.

1. Install Cypress using npm: npm install cypress --save-dev 2. Open Cypress with npx cypress open 3. Create a new test file named first_test.cy.js inside cypress/e2e folder.

Result

Cypress opens its Test Runner window, ready to run tests from your new file.

Knowing how to set up Cypress is the first step to writing any test; without this, you cannot start testing.

2

Foundation

Write Basic Test Structure

Concept: Understand the basic syntax to write a Cypress test with describe and it blocks.

In first_test.cy.js, write: describe('My First Test', () => { it('Visits a website', () => { // test steps go here }) })

Result

A test suite named 'My First Test' with one test case 'Visits a website' is defined but does nothing yet.

Tests are organized in suites and cases; this structure helps keep tests clear and grouped logically.

3

Intermediate

Visit a Web Page

🤔Before reading on: do you think the test will open the website automatically or do you need extra commands? Commit to your answer.

Concept: Learn to use cy.visit() to open a web page inside the test.

Add cy.visit('https://example.cypress.io') inside the it block: it('Visits a website', () => { cy.visit('https://example.cypress.io') })

Result

When running the test, Cypress opens the browser and loads the specified URL.

Understanding cy.visit() is key because it tells Cypress where to start testing, just like opening a book to the right page.

4

Intermediate

Add Simple Assertion

🤔Before reading on: do you think Cypress checks page content automatically or do you have to tell it what to check? Commit to your answer.

Concept: Learn to check if the page contains expected text using cy.contains() and assertions.

Extend the test: it('Visits a website and checks content', () => { cy.visit('https://example.cypress.io') cy.contains('type') })

Result

The test passes if the page shows the word 'type'; it fails if not found.

Assertions confirm the website behaves as expected; without them, tests don't prove anything.

5

Advanced

Run Test and Interpret Results

🤔Before reading on: do you think Cypress shows detailed info about test success or just pass/fail? Commit to your answer.

Concept: Learn how to run the test in Cypress Test Runner and understand the output and logs.

Click the test name in Cypress Test Runner to run it. Watch the browser open, commands run step-by-step, and results appear in the sidebar.

Result

You see green checkmarks for passed commands and a clear pass/fail test result summary.

Seeing detailed command logs helps debug tests and understand exactly what Cypress does during testing.

6

Expert

Understand Cypress Command Queue and Async Nature

🤔Before reading on: do you think Cypress commands run immediately or are queued and run later? Commit to your answer.

Concept: Learn that Cypress commands are queued and run asynchronously, which affects how tests are written and debugged.

Cypress collects commands like cy.visit() and cy.contains() in a queue. It runs them one by one automatically. This means you cannot use normal JavaScript timing or expect immediate results after commands.

Result

Tests run smoothly without manual waits, but writing code that assumes immediate execution causes errors.

Understanding Cypress's command queue prevents common mistakes and helps write reliable, clean tests.

Under the Hood

Cypress runs inside the browser as a special JavaScript program. It controls the browser by injecting commands that simulate user actions. It queues these commands and executes them step-by-step, waiting for each to finish before moving on. It also watches the page for changes to confirm assertions. This all happens in real time, giving instant feedback.

Why designed this way?

Cypress was designed to run inside the browser to avoid flakiness and timing issues common in older tools that control browsers externally. This design gives faster, more reliable tests and better debugging because it has full access to the page's internals.

┌───────────────┐
│ Test Code     │
│ (cy.visit,    │
│  cy.contains) │
└──────┬────────┘
       │ Queued commands
       ▼
┌───────────────┐
│ Cypress Runner│
│ Executes cmds │
└──────┬────────┘
       │ Controls browser
       ▼
┌───────────────┐
│ Browser       │
│ Loads page,   │
│ Runs commands │
└───────────────┘

Myth Busters - 3 Common Misconceptions

Quick: Do you think Cypress tests run commands immediately one after another like normal JavaScript? Commit to yes or no.

Common Belief: Cypress commands run immediately and synchronously like normal JavaScript.

Reality: Cypress commands are queued and run asynchronously one by one, not immediately.

Why it matters: Assuming immediate execution causes timing bugs and test failures because commands may not have completed when you check results.

Quick: Do you think Cypress can test any website without restrictions? Commit to yes or no.

Common Belief: Cypress can test all websites, including those on different domains or with strict security.

Reality: Cypress runs in the browser and has limitations with cross-origin sites and some security policies.

Why it matters: Trying to test unsupported sites leads to errors and wasted time; knowing limits helps choose the right tool.

Quick: Do you think writing a test without assertions still proves the app works? Commit to yes or no.

Common Belief: Just running commands like visiting pages is enough to test the app.

Reality: Without assertions, tests don't verify anything and can pass even if the app is broken.

Why it matters: Missing assertions means bugs go unnoticed, defeating the purpose of testing.

Expert Zone

1

Cypress automatically waits for elements to appear and commands to complete, reducing the need for manual waits.

2

Tests run inside the browser context, so you can access window and document objects directly for advanced checks.

3

Cypress retries assertions until they pass or timeout, making tests more stable against slow-loading pages.

When NOT to use

Cypress is not ideal for testing non-web applications or websites with complex multi-domain flows. For those, tools like Playwright or Selenium might be better.

Production Patterns

In real projects, tests are organized into folders by feature, use custom commands for repeated actions, and run automatically in CI/CD pipelines to catch bugs before release.

Connections

Unit Testing

Builds-on

Understanding Cypress tests helps grasp how automated tests verify code behavior, similar to unit tests but for full web pages.

Robotics Automation

Same pattern

Both Cypress and robotics automation involve programming a machine to perform tasks step-by-step and check results, showing how automation principles apply across fields.

User Experience Design

Builds-on

Cypress tests simulate real user actions, helping designers and developers ensure the website feels smooth and works as intended.

Common Pitfalls

#1 Writing tests without assertions to check results.

Wrong approach:

describe('Test', () => {
it('Visits page', () => {
cy.visit('https://example.com')
})
})

Correct approach:

describe('Test', () => {
it('Visits page and checks title', () => {
cy.visit('https://example.com')
cy.title().should('include', 'Example')
})
})

Root cause:

Beginners think visiting a page alone proves success, missing that tests must confirm expected outcomes.

#2 Using JavaScript commands expecting immediate results after Cypress commands.

Wrong approach:

cy.visit('https://example.com')
const title = document.title
expect(title).to.equal('Example')

Correct approach:

cy.visit('https://example.com')
cy.title().should('equal', 'Example')

Root cause:

Misunderstanding Cypress's asynchronous command queue and trying to access page state too early.

#3 Hardcoding waits instead of relying on Cypress automatic waits.

Wrong approach:

cy.visit('https://example.com')
cy.wait(5000)
cy.get('button').click()

Correct approach:

cy.visit('https://example.com')
cy.get('button').click()

Root cause:

Beginners use fixed delays, which slow tests and cause flakiness instead of letting Cypress wait for elements.

Key Takeaways

Cypress tests simulate user actions in a real browser to check if websites work correctly.

Tests must include assertions to verify expected results; visiting pages alone is not enough.

Cypress commands run asynchronously in a queue, so tests must use Cypress methods to check results safely.

Cypress automatically waits for elements and retries assertions, making tests more stable and easier to write.

Understanding Cypress's design helps avoid common mistakes and write reliable, maintainable tests.