Why assertions verify expected behavior in Cypress - Why It Works This Way

Overview - Why assertions verify expected behavior

What is it?

Assertions are checks in tests that confirm if the software behaves as expected. They compare actual results with what should happen. In Cypress, assertions help verify that web elements, data, or actions meet the requirements. Without assertions, tests would not know if the software works correctly or not.

Why it matters

Assertions exist to catch mistakes early by automatically checking if the software does what it should. Without assertions, testers would have to look at results manually, which is slow and error-prone. This could let bugs slip into real use, causing frustration or failures. Assertions make testing faster, reliable, and repeatable.

Where it fits

Before learning assertions, you should understand basic test writing and how Cypress interacts with web pages. After mastering assertions, you can learn advanced test strategies like test data setup, mocking, and continuous integration testing.

Mental Model

Core Idea

Assertions are automatic truth-checkers that confirm software behaves exactly as expected during tests.

Think of it like...

Assertions are like a checklist you use when packing for a trip: you verify you have your passport, tickets, and clothes before leaving. If something is missing, you know immediately and can fix it.

┌───────────────┐
│   Test Runs   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│  Assertions   │
│ (Checks True) │
└──────┬────────┘
       │
  Pass │ Fail
       ▼     ▼
  Continue  Report Bug
  Testing

Build-Up - 6 Steps

1

Foundation

What is an Assertion in Testing

Concept: Introduce the basic idea of an assertion as a check in a test.

An assertion is a statement in a test that says: 'This must be true.' For example, checking if a button is visible on a page. In Cypress, you write assertions using commands like cy.get('button').should('be.visible'). This tells Cypress to look for the button and confirm it is visible.

Result

If the button is visible, the assertion passes and the test continues. If not, the test fails and stops.

Understanding assertions as simple true/false checks helps you see how tests automatically verify software behavior.

2

Foundation

How Assertions Fit in Cypress Tests

Concept: Explain how assertions are part of the test flow in Cypress.

Cypress commands find elements or perform actions, then assertions check if the results match expectations. For example, cy.get('input').type('hello').should('have.value', 'hello') types text and asserts the input holds that text. Assertions are the checkpoints that confirm each step worked.

Result

Tests with assertions give clear pass/fail results based on expected behavior.

Knowing that assertions are checkpoints in test steps helps you write tests that catch errors exactly where they happen.

3

Intermediate

Common Assertion Types in Cypress

🤔Before reading on: do you think assertions only check if elements exist, or can they check other things too? Commit to your answer.

Concept: Introduce different kinds of assertions beyond existence, like visibility, text content, and attributes.

Cypress supports many assertions: 'exist' checks presence, 'be.visible' checks if element is shown, 'contain' checks text inside, 'have.class' checks CSS classes, and 'have.value' checks input values. You can combine these to verify complex behaviors.

Result

Using varied assertions lets you test many aspects of UI and data correctness.

Understanding the variety of assertions lets you write precise tests that cover all important behaviors.

4

Intermediate

Assertions and Test Reliability

🤔Before reading on: do you think assertions make tests slower or more reliable? Commit to your answer.

Concept: Explain how assertions improve test reliability by catching unexpected states early.

Assertions stop tests immediately when something is wrong, preventing false passes. Cypress retries commands and assertions automatically until they pass or timeout, making tests stable even with slow loading. This reduces flaky tests and increases confidence.

Result

Tests with assertions are more trustworthy and easier to maintain.

Knowing that assertions improve reliability helps you appreciate their role beyond simple checks.

5

Advanced

Custom Assertions for Complex Checks

🤔Before reading on: do you think built-in assertions cover all cases, or might you need custom ones? Commit to your answer.

Concept: Show how to create custom assertions in Cypress for special needs.

Sometimes built-in assertions are not enough. Cypress allows writing custom assertions using .should(callback) where you write your own logic. For example, checking if a list is sorted or if a value matches a pattern. This extends test power.

Result

Custom assertions let you verify complex or unique behaviors not covered by defaults.

Understanding custom assertions unlocks advanced testing scenarios and deeper verification.

6

Expert

Assertions Impact on Test Design and Debugging

🤔Before reading on: do you think placing assertions early or late in tests affects debugging ease? Commit to your answer.

Concept: Explore how strategic assertion placement helps isolate failures and speeds debugging.

Placing assertions right after important actions helps catch exactly where behavior breaks. Cypress's clear error messages from failed assertions guide debugging. Overusing assertions can slow tests, so balance is key. Experts design tests with meaningful assertions that document expected behavior clearly.

Result

Well-placed assertions make tests self-documenting and debugging faster.

Knowing how assertions shape test clarity and debugging efficiency is a mark of expert test design.

Under the Hood

Cypress runs tests in the browser and controls the page. When it hits an assertion, it repeatedly checks the condition until it passes or a timeout occurs. This retry mechanism handles delays like slow loading. If the assertion fails, Cypress stops the test and reports the failure with details about what was expected and what was found.

Why designed this way?

Cypress was designed to handle real-world web app delays and asynchronous behavior. The retrying assertions reduce flaky tests caused by timing issues. This design makes tests more stable and developer-friendly compared to older tools that failed immediately on first check.

┌───────────────┐
│  Test Script  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Cypress Engine│
│  Executes and │
│  Controls DOM │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Assertion     │
│  Check Loop   │
│ (Retry until  │
│  pass/timeout)│
└──────┬────────┘
       │
  Pass │ Fail
       ▼     ▼
 Continue  Report
 Testing  Failure

Myth Busters - 4 Common Misconceptions

Quick: Do assertions only check if elements exist, or can they check many other things? Commit to your answer.

Common Belief: Assertions only check if an element exists on the page.

Reality: Assertions can check many things like visibility, text content, attributes, and even custom conditions.

Why it matters: Believing assertions only check existence limits test coverage and misses bugs in UI behavior or data.

Quick: Do assertions slow down tests significantly, or do they improve reliability? Commit to your answer.

Common Belief: Assertions make tests slower and should be minimized.

Reality: Assertions improve test reliability by catching errors early and retrying until stable, reducing flaky tests.

Why it matters: Avoiding assertions to speed tests leads to unreliable tests that miss bugs or give false passes.

Quick: Can you write your own assertions in Cypress, or must you use only built-in ones? Commit to your answer.

Common Belief: You can only use the built-in assertions Cypress provides.

Reality: Cypress allows custom assertions using callback functions for complex checks.

Why it matters: Not knowing about custom assertions limits your ability to test unique or complex behaviors.

Quick: Does placing assertions late in tests make debugging easier or harder? Commit to your answer.

Common Belief: It doesn't matter where assertions are placed in tests.

Reality: Placing assertions early after actions helps isolate failures and speeds debugging.

Why it matters: Poor assertion placement makes it harder to find the cause of test failures, wasting time.

Expert Zone

1

Assertions in Cypress automatically retry until timeout, which handles asynchronous web behavior gracefully.

2

Custom assertions can access the full DOM element and test complex conditions beyond simple property checks.

3

Strategic assertion placement acts as documentation, making tests easier to understand and maintain.

When NOT to use

Assertions are not suitable for checking things outside the test scope, like external system states or logs. For those, use API tests or monitoring tools. Also, avoid excessive assertions that slow tests without adding value.

Production Patterns

In real projects, assertions are combined with fixtures and mocks to isolate tests. Teams use assertion libraries like Chai with Cypress for expressive checks. Assertions are placed after every critical step to catch failures early and improve test reliability.

Connections

Debugging

Assertions provide immediate feedback that helps locate bugs quickly during debugging.

Knowing how assertions fail clearly helps developers fix problems faster and write better code.

Continuous Integration (CI)

Assertions enable automated tests in CI pipelines to verify software quality before deployment.

Understanding assertions helps appreciate how automated testing gates prevent broken code from reaching users.

Scientific Method

Assertions are like hypotheses tests that confirm or reject expected outcomes in experiments.

Seeing assertions as hypothesis checks connects software testing to broader problem-solving and validation processes.

Common Pitfalls

#1 Skipping assertions and relying on manual checks.

Wrong approach:

cy.get('button').click(); // no assertion after click

Correct approach:

cy.get('button').click().should('be.disabled');

Root cause:

Misunderstanding that tests need automatic checks to confirm behavior, not just actions.

#2 Using assertions that are too broad or vague.

Wrong approach:

cy.get('div').should('exist'); // too general

Correct approach:

cy.get('div#main-content').should('be.visible').and('contain', 'Welcome');

Root cause:

Not specifying precise expected behavior leads to weak tests that miss bugs.

#3 Placing assertions only at the end of long test flows.

Wrong approach:

cy.get('input').type('text');
cy.get('button').click();
// no assertions until end

Correct approach:

cy.get('input').type('text').should('have.value', 'text');
cy.get('button').click().should('be.disabled');

Root cause:

Failing to check intermediate states makes debugging failures harder.

Key Takeaways

Assertions are essential checks that confirm software behaves as expected during tests.

Cypress assertions automatically retry, making tests stable even with slow or asynchronous web pages.

Using a variety of assertions lets you verify many aspects of UI and data correctness precisely.

Custom assertions extend testing power to complex or unique conditions beyond built-in checks.

Strategic placement of assertions improves test clarity and speeds up debugging when failures occur.