The Commands You'll Use Every Day
The vast majority of Cypress tests are built from a small core vocabulary: cy.visit() to load a page, cy.get()/cy.contains() to locate elements, .click()/.type()/.check()/.select() to interact with them, and .should()/.and() to assert on the result. Because every one of these commands is retry-aware, a chain like cy.get('[data-cy=list-item]').should('have.length', 3) will keep re-querying the DOM and re-checking the length until it's true or the default timeout (4 seconds, configurable via defaultCommandTimeout) elapses, so you rarely need to manually poll for asynchronous UI updates like a list populating after a fetch completes.
Cricket analogy: A batter's core toolkit — the forward defensive, the cover drive, the pull shot — covers the vast majority of deliveries faced in a career, just as cy.get, .click, .type, and .should cover the vast majority of Cypress test code.
// Navigation and locating
cy.visit('/products');
cy.get('[data-cy=search-input]');
cy.contains('Add to cart');
// Interaction
cy.get('[data-cy=search-input]').type('running shoes{enter}');
cy.get('[data-cy=category-filter]').select('Footwear');
cy.get('[data-cy=in-stock-only]').check();
cy.get('[data-cy=add-to-cart]').click();
// Assertions
cy.get('[data-cy=cart-count]').should('have.text', '1');
cy.get('[data-cy=product-list]').should('have.length', 12);
cy.url().should('include', '/products');
cy.get('[data-cy=price]').should('be.visible').and('contain', '$');Network Mocking with cy.intercept and Fixtures
cy.intercept() is the modern replacement for the older cy.route() (removed in Cypress 10+) and can either spy on a real request or stub it entirely with a fixed response using cy.fixture(). A typical pattern aliases the intercept with .as('getProducts') and then uses cy.wait('@getProducts') to pause the test until that specific network call resolves, which is far more precise than an arbitrary delay. Stubbing is especially useful for testing edge cases that are hard to reproduce against a real backend, such as a 500 server error, an empty result set, or a slow response, by setting statusCode and body directly in the intercept handler or delaying the response with delay.
Cricket analogy: A coach sets up a bowling machine to reliably reproduce a specific delivery type — a yorker at leg stump — for practice, something a live bowler can't guarantee every time, similar to cy.intercept stubbing a specific hard-to-reproduce server response.
// Stub a successful response from a fixture file
cy.intercept('GET', '/api/products', { fixture: 'products.json' }).as('getProducts');
cy.visit('/products');
cy.wait('@getProducts');
cy.get('[data-cy=product-card]').should('have.length', 12);
// Stub an error response inline
cy.intercept('GET', '/api/products', {
statusCode: 500,
body: { message: 'Internal Server Error' },
}).as('getProductsError');
cy.visit('/products');
cy.wait('@getProductsError');
cy.get('[data-cy=error-banner]').should('be.visible');cy.route() and the older XHR-based intercept API were removed in Cypress 10. If you're maintaining an older codebase, migrating cy.route()/cy.server() calls to cy.intercept() is mandatory to upgrade past Cypress 9, and the syntax and matching semantics (glob/regex URL matching, RouteMatcher objects) differ meaningfully.
Configuration and Custom Commands Cheat Sheet
Project-wide behavior lives in cypress.config.js/ts under the e2e and component keys: baseUrl avoids repeating the origin in every cy.visit(), defaultCommandTimeout controls how long retry-able commands wait, viewportWidth/viewportHeight set the default browser size, and env holds custom environment variables accessible via Cypress.env(). Custom commands are registered in cypress/support/commands.js via Cypress.Commands.add('name', fn) and are then callable as cy.name(...) anywhere in the suite; TypeScript users should also augment the global Cypress.Chainable interface in a .d.ts file so custom commands get type-checking and autocomplete.
Cricket analogy: A ground's standing playing conditions — pitch report, boundary rope distance, over rate rules — are set once before a series and apply to every match, similar to cypress.config.js settings applying across the whole suite.
Useful CLI flags: cypress run --browser chrome (choose browser), --headed (watch it run), --spec 'cypress/e2e/checkout/**' (run a subset), --env grepTags=smoke (with the cypress-grep plugin, run tagged tests only), and --record --key <key> --parallel for CI-recorded parallel runs.
- Core commands cy.visit, cy.get, cy.contains, .click, .type, .should cover the bulk of everyday test writing.
- All Cypress commands retry automatically up to defaultCommandTimeout (4s by default), removing the need for manual polling.
- cy.intercept() replaced the removed cy.route()/cy.server() APIs starting in Cypress 10.
- Alias intercepts with .as() and synchronize with cy.wait('@alias') instead of arbitrary delays.
- Use cy.fixture() and inline statusCode/body/delay options in cy.intercept() to simulate edge cases like errors or slow responses.
- Global settings (baseUrl, viewport, timeouts, env vars) live in cypress.config.js/ts and apply across the whole suite.
- Register reusable custom commands with Cypress.Commands.add() in cypress/support/commands.js.
Practice what you learned
1. What replaced cy.route() and cy.server() starting in Cypress 10?
2. What does chaining .as('getProducts') onto a cy.intercept() call enable?
3. What is the default value of defaultCommandTimeout in Cypress, and what does it control?
4. How would you simulate a server returning a 500 error for a specific API call in a Cypress test?
5. Where should project-wide settings like baseUrl and viewport dimensions be configured?
Was this page helpful?
You May Also Like
Cypress Best Practices
A practical guide to writing Cypress tests that are fast, resilient to UI changes, and free of the flakiness that erodes trust in a test suite.
Building an E2E Test Suite with Cypress
A step-by-step approach to designing, implementing, and running a Cypress end-to-end test suite for a realistic e-commerce-style application.
Cypress vs Selenium vs Playwright
A technical comparison of the three major browser automation tools, covering architecture, language support, speed, and when each is the right choice.