Resource library

QA How-To

Cypress Tutorial for Beginners (2026)

Follow a Cypress tutorial for beginners with setup, stable queries, retries, network control, sessions, component tests, CI, debugging, and interviews.

24 min read | 3,420 words

TL;DR

Set up Cypress, run one meaningful scenario, and make state, synchronization, assertions, cleanup, and diagnostics explicit. Expand coverage by product risk, not script count.

Key Takeaways

Understand the Cypress execution model before adding framework layers.
Build one runnable scenario with supported public APIs.
Use stable identifiers, controlled data, and observable assertions.
Synchronize on readiness instead of fixed delays.
Preserve useful artifacts at the first failure.
Scale in CI only after local execution is deterministic.

Cypress tutorial for beginners is a practical process for turning intent into repeatable evidence. This guide starts with the execution model, builds a runnable example with supported APIs, and then covers design, debugging, CI, common mistakes, and interview reasoning.

The examples favor clarity over framework ceremony. You can adapt paths and application-specific values without inventing commands or hiding the important lifecycle.

TL;DR

Need	Cypress approach	Why
Stable element	`data-cy` selector	Decoupled from layout
Network synchronization	`cy.intercept()` plus alias	Waits for meaningful event
Repeated login	`cy.session()`	Cached validated setup
Cross-origin flow	`cy.origin()`	Explicit origin boundary

Start with one deterministic scenario. Make state, data, dependencies, assertions, cleanup, and diagnostics explicit before scaling the suite.

1. How Cypress Executes Browser Tests

Cypress runs test code with privileged access alongside the browser application and coordinates commands through its runner. Commands are queued and retried according to built-in rules, so Cypress chains are not ordinary synchronous values or promises.

How Cypress Executes Browser Tests requires deliberate scope. Start with one representative success case, then add the boundary and failure that would create the greatest customer or release risk. Record the environment, data, and expected evidence. This makes the example repeatable and prevents a green result from meaning only that no exception was thrown.

Do not optimize for the number of scripts. Optimize for diagnostic value and stable feedback. Review the behavior with developers and product owners, especially when the tool reveals an ambiguous contract. Once the narrow case is trustworthy, refactor repeated setup and extend coverage without changing the original intent.

In practice, this connects to the JavaScript testing guide. Use that related guide when the scenario crosses the current tool boundary.

Before considering this area complete, run a review from three viewpoints. A product reviewer should confirm the rule and customer outcome. An engineer should confirm interfaces, state, and observability. A tester should challenge boundaries, concurrency, recovery, and unsupported assumptions. Capture decisions in the source artifact, then update the executable evidence. This review is especially valuable when a passing script can mask an incorrect oracle or incomplete setup.

2. Cypress Tutorial for Beginners: Project Setup

Create a Node project, install Cypress as a development dependency, open it once to scaffold configuration, and choose end-to-end testing. Keep the generated configuration in version control and the binary cache outside it.

Cypress Tutorial for Beginners: Project Setup requires deliberate scope. Start with one representative success case, then add the boundary and failure that would create the greatest customer or release risk. Record the environment, data, and expected evidence. This makes the example repeatable and prevents a green result from meaning only that no exception was thrown.

In practice, this connects to the API testing tutorial. Use that related guide when the scenario crosses the current tool boundary.

3. Write and Run the First End-to-End Test

Prefer accessible queries through Testing Library when adopted, stable data attributes for application-specific controls, and scoped semantic text where copy is part of behavior. Avoid CSS paths tied to layout and arbitrary waits.

Write and Run the First End-to-End Test requires deliberate scope. Start with one representative success case, then add the boundary and failure that would create the greatest customer or release risk. Record the environment, data, and expected evidence. This makes the example repeatable and prevents a green result from meaning only that no exception was thrown.

The following example is intentionally small and uses supported public interfaces. Replace paths and application values, but keep the lifecycle and cleanup pattern.

npm init -y
npm install --save-dev cypress
npx cypress open

// cypress/e2e/login.cy.js
describe("login", () => {
  it("shows the dashboard for a valid user", () => {
    cy.intercept("POST", "**/api/login").as("login");
    cy.visit("/login");
    cy.get("[data-cy=email]").type("qa.user@example.test");
    cy.get("[data-cy=password]").type("correct-test-password", { log: false });
    cy.get("[data-cy=submit]").click();
    cy.wait("@login").its("response.statusCode").should("eq", 200);
    cy.location("pathname").should("eq", "/dashboard");
    cy.contains("h1", "Dashboard").should("be.visible");
  });
});

4. Understand Command Chains and Retryability

Translate this topic into a small observable workflow. Define the starting state, perform one business action, and assert the visible result plus any important service, event, or persistence outcome. Keep setup separate from the behavior under test so a failure points to one useful cause.

Understand Command Chains and Retryability requires deliberate scope. Start with one representative success case, then add the boundary and failure that would create the greatest customer or release risk. Record the environment, data, and expected evidence. This makes the example repeatable and prevents a green result from meaning only that no exception was thrown.

Need	Cypress approach	Why
Stable element	`data-cy` selector	Decoupled from layout
Network synchronization	`cy.intercept()` plus alias	Waits for meaningful event
Repeated login	`cy.session()`	Cached validated setup
Cross-origin flow	`cy.origin()`	Explicit origin boundary

5. Select Elements Without Fragile CSS

Reliability depends on synchronization and isolation. Wait for meaningful readiness instead of elapsed time, use synthetic data with clear ownership, and reset only the state the scenario changes. Preserve the first failure because automatic repetition can erase evidence of a race or shared-state defect.

Select Elements Without Fragile CSS requires deliberate scope. Start with one representative success case, then add the boundary and failure that would create the greatest customer or release risk. Record the environment, data, and expected evidence. This makes the example repeatable and prevents a green result from meaning only that no exception was thrown.

In practice, this connects to the API testing tutorial. Use that related guide when the scenario crosses the current tool boundary.

6. Control and Observe Network Requests

Design for maintainers who did not write the first version. Use names that express intent, keep configuration explicit, and avoid helpers that conceal important state transitions. A helper should reduce duplication while leaving the test's business story readable.

Control and Observe Network Requests requires deliberate scope. Start with one representative success case, then add the boundary and failure that would create the greatest customer or release risk. Record the environment, data, and expected evidence. This makes the example repeatable and prevents a green result from meaning only that no exception was thrown.

Keep a short decision record beside the test. Note what is intentionally covered, what is delegated to another layer, and what remains untested. This prevents future maintainers from confusing an omission with a deliberate risk decision and gives reviewers a concrete basis for changing scope.

7. Manage Authentication and Test Data

Negative coverage matters here. Exercise invalid input, missing permission, dependency failure, timeout, repeated action, and recovery where those risks apply. Verify not only the error message but also the absence of forbidden side effects and the presence of useful diagnostics.

Manage Authentication and Test Data requires deliberate scope. Start with one representative success case, then add the boundary and failure that would create the greatest customer or release risk. Record the environment, data, and expected evidence. This makes the example repeatable and prevents a green result from meaning only that no exception was thrown.

8. Test Components and Multiple Origins

When diagnosis begins, identify the failing layer before editing code. Capture configuration, environment identity, logs, screenshots or reports, and the earliest meaningful error. Reproduce with the same inputs, then change one variable at a time so the conclusion is defensible.

Test Components and Multiple Origins requires deliberate scope. Start with one representative success case, then add the boundary and failure that would create the greatest customer or release risk. Record the environment, data, and expected evidence. This makes the example repeatable and prevents a green result from meaning only that no exception was thrown.

9. Debug Failures and Collect Evidence

For CI, build the same command used locally into a clean, noninteractive job. Pin dependencies with the project lockfile, inject secrets at runtime, set an intentional timeout, and upload useful artifacts even when execution fails. Parallel workers need isolated data and resources.

Debug Failures and Collect Evidence requires deliberate scope. Start with one representative success case, then add the boundary and failure that would create the greatest customer or release risk. Record the environment, data, and expected evidence. This makes the example repeatable and prevents a green result from meaning only that no exception was thrown.

10. Cypress Tutorial for Beginners: CI and Suite Design

A sustainable suite has a fast critical path, focused rule tests, and a smaller number of expensive integrated scenarios. Review slow and flaky tests as engineering work. Remove redundant checks and move setup through supported APIs when the UI is not the subject of the test.

Cypress Tutorial for Beginners: CI and Suite Design requires deliberate scope. Start with one representative success case, then add the boundary and failure that would create the greatest customer or release risk. Record the environment, data, and expected evidence. This makes the example repeatable and prevents a green result from meaning only that no exception was thrown.

Interview Questions and Answers

Q: How is Cypress different from Selenium?

How is Cypress different from Selenium is best answered from the execution model, not from a memorized definition. I explain the intended behavior, name the relevant boundary or dependency, and give one concrete example from Cypress. I also state how I would observe failure and keep the test isolated. That answer demonstrates both tool knowledge and engineering judgment.

Q: Why are Cypress commands not normal promises?

Why are Cypress commands not normal promises is best answered from the execution model, not from a memorized definition. I explain the intended behavior, name the relevant boundary or dependency, and give one concrete example from Cypress. I also state how I would observe failure and keep the test isolated. That answer demonstrates both tool knowledge and engineering judgment.

Q: What does retryability mean?

What does retryability mean is best answered from the execution model, not from a memorized definition. I explain the intended behavior, name the relevant boundary or dependency, and give one concrete example from Cypress. I also state how I would observe failure and keep the test isolated. That answer demonstrates both tool knowledge and engineering judgment.

Q: When do you use cy.intercept?

When do you use cy.intercept is best answered from the execution model, not from a memorized definition. I explain the intended behavior, name the relevant boundary or dependency, and give one concrete example from Cypress. I also state how I would observe failure and keep the test isolated. That answer demonstrates both tool knowledge and engineering judgment.

Q: How do you test authentication efficiently?

How do you test authentication efficiently is best answered from the execution model, not from a memorized definition. I explain the intended behavior, name the relevant boundary or dependency, and give one concrete example from Cypress. I also state how I would observe failure and keep the test isolated. That answer demonstrates both tool knowledge and engineering judgment.

Q: How do you handle another origin?

How do you handle another origin is best answered from the execution model, not from a memorized definition. I explain the intended behavior, name the relevant boundary or dependency, and give one concrete example from Cypress. I also state how I would observe failure and keep the test isolated. That answer demonstrates both tool knowledge and engineering judgment.

Q: What makes a Cypress selector stable?

What makes a Cypress selector stable is best answered from the execution model, not from a memorized definition. I explain the intended behavior, name the relevant boundary or dependency, and give one concrete example from Cypress. I also state how I would observe failure and keep the test isolated. That answer demonstrates both tool knowledge and engineering judgment.

Q: How do you debug CI-only failures?

How do you debug CI-only failures is best answered from the execution model, not from a memorized definition. I explain the intended behavior, name the relevant boundary or dependency, and give one concrete example from Cypress. I also state how I would observe failure and keep the test isolated. That answer demonstrates both tool knowledge and engineering judgment.

Common Mistakes

Assigning a Cypress chain to a plain variable: Identify the hidden assumption, replace it with an explicit contract, and add evidence at the failing layer. Mistake 1 often creates misleading failures or false confidence.
Using cy.wait with an arbitrary millisecond delay: Identify the hidden assumption, replace it with an explicit contract, and add evidence at the failing layer. Mistake 2 often creates misleading failures or false confidence.
Selecting elements by changing layout classes: Identify the hidden assumption, replace it with an explicit contract, and add evidence at the failing layer. Mistake 3 often creates misleading failures or false confidence.
Stubbing every request in end-to-end tests: Identify the hidden assumption, replace it with an explicit contract, and add evidence at the failing layer. Mistake 4 often creates misleading failures or false confidence.
Reusing dirty data between tests: Identify the hidden assumption, replace it with an explicit contract, and add evidence at the failing layer. Mistake 5 often creates misleading failures or false confidence.
Hiding first-attempt failures with retries: Identify the hidden assumption, replace it with an explicit contract, and add evidence at the failing layer. Mistake 6 often creates misleading failures or false confidence.

Conclusion

Cypress tutorial for beginners becomes useful when the smallest complete feedback loop is reliable. Understand the architecture, control setup and data, use supported interfaces, synchronize on observable state, and preserve failure evidence.

Run the example from a clean environment, force one failure, diagnose it from artifacts, and restore a passing run. Then add one risk-driven scenario at a time.

Interview Questions and Answers

How is Cypress different from Selenium?

Why are Cypress commands not normal promises?

What does retryability mean?

When do you use cy.intercept?

How do you test authentication efficiently?

How do you handle another origin?

What makes a Cypress selector stable?

How do you debug CI-only failures?

Frequently Asked Questions

What should I learn before Cypress?

Start with the core execution model and one complete scenario. Keep data and environment controlled, use current supported interfaces, and collect evidence for failures. Add abstractions and parallel execution only after the basic workflow is deterministic.

Cypress Tutorial for Beginners (2026)

TL;DR

Key Takeaways

TL;DR

1. How Cypress Executes Browser Tests

2. Cypress Tutorial for Beginners: Project Setup

3. Write and Run the First End-to-End Test

4. Understand Command Chains and Retryability

5. Select Elements Without Fragile CSS

6. Control and Observe Network Requests

7. Manage Authentication and Test Data

8. Test Components and Multiple Origins

9. Debug Failures and Collect Evidence

10. Cypress Tutorial for Beginners: CI and Suite Design

Interview Questions and Answers

Common Mistakes

Conclusion

Interview Questions and Answers

How is Cypress different from Selenium?

Why are Cypress commands not normal promises?

What does retryability mean?

When do you use cy.intercept?

How do you test authentication efficiently?

How do you handle another origin?

What makes a Cypress selector stable?

How do you debug CI-only failures?

Frequently Asked Questions

What should I learn before Cypress?

Is Cypress suitable for beginners?

How long does it take to learn Cypress?

How should Cypress run in CI?

How do I reduce flaky Cypress tests?

What should a first Cypress project contain?

How do I debug a failing Cypress test?

Should every test use Cypress?

Related Guides