Cypress Example Recipes

repository·master·Indexed 26 days ago

https://github.com/cypress-io/cypress-example-recipes

A comprehensive collection of practical Cypress testing recipes. Covers common scenarios including DOM manipulation, authentication, network stubbing, server communication, accessibility testing with cypress-axe, Application Actions, iframe interaction, and API testing using cy.request().

Tokens
20.5K
Snippets
59
Records
165
Agent score
86%

What's inside cypress-example-recipes

  1. Understand the Cypress project folder structure

    master

    Cypress projects typically follow a specific directory structure to organize test data, test files, and global configuration:

    • fixtures/: Used for storing optional JSON data for mocking and stubbing.
    • e2e/: The directory where actual test files are located.
    • support/: Contains files that run before all tests. This is the recommended location for defining or loading custom commands.
  2. Testing Redux store patterns

    master

    This recipe demonstrates several patterns for testing applications using Redux:

    • DOM-driven testing: Control the application via the DOM and verify that the Redux store updates correctly.
    • Action-driven testing: Drive the application by dispatching Redux actions directly from your tests.
    • State loading: Load an initial Redux state from a fixture file.
    • State assertion: Assert the entire store state using a single deep.equal assertion.
    • Retry logic: Use automatic user function retries with cypress-pipe for more resilient tests.
  3. Explore Cypress Recipes

    master

    This repository provides a collection of practical recipes for common testing scenarios in Cypress. It is organized into several functional categories to help you solve specific testing challenges:

    • Fundamentals: Core Cypress capabilities like custom commands, environment variables, fixtures, and dynamic tests.
    • Testing the DOM: Handling complex UI interactions like Shadow DOM, drag and drop, iframes, and pagination.
    • Logging In: Strategies for various authentication methods including Basic Auth, SSO, JWT, and CSRF tokens.
    • Preprocessors: Configuring support for tools like TypeScript, Webpack, Browserify, and Flow.
    • Stubbing and Spying: Controlling network traffic with cy.intercept and mocking JavaScript functions or browser APIs (like window.fetch or console.log).
    • Unit Testing: Importing and testing application code directly.
    • Server Communication: Managing test data, seeding databases, and handling HTTP requests via cy.request or cy.task.
  4. Enable IntelliSense for custom Chai assertions

    master

    To get intelligent code completion for custom assertions in JavaScript spec files, follow these steps:

    1. Create a .d.ts file (e.g., cypress/support/index.d.ts) containing the type definitions for the Cypress.Chainer interface. Use JSDoc comments to provide descriptions and examples.
    2. In your spec file, add a /// <reference path="..." /> comment pointing to your .d.ts file to load the definitions.
    // cypress/support/index.d.ts file
    /// <reference types="cypress" />
    
    declare namespace Cypress {
      interface Chainer<Subject> {
        /**
         * Custom Chai assertion that checks if given subject is string "foo"
         * @example
         * expect('foo').to.be.foo()
         * cy.wrap('foo').should('be.foo')
         */
        (chainer: 'be.foo'): Chainable<Subject>
    
        /**
         * Custom Chai assertion that checks if given subject is NOT string "foo"
         * @example
         * expect('bar').to.not.be.foo()
         * cy.wrap('bar').should('not.be.foo')
         */
       (chainer: 'not.be.foo'): Chainable<Subject>
      }
    }
    // In your spec file
    /// <reference types="Cypress" />
    /// <reference path="../support/index.d.ts" />
  5. Add custom commands using TypeScript

    master

    To use custom Cypress commands with TypeScript support (IntelliSense) without a tsconfig.json file, you must use triple-slash directive references in your spec files to point to your custom type definitions.

    1. Define your custom command types in a declaration file (e.g., cypress/support/index.d.ts).
    2. Reference that declaration file at the top of your spec files using the /// <reference path="..." /> syntax.
    // cypress/e2e/spec.ts
    /// <reference path="../support/index.d.ts" />
  6. Pass environment variables to Cypress tests

    master

    You can pass environment variables to your Cypress tests using several methods depending on the scope and security requirements:

    1. Automatic Extraction: Any environment variable starting with CYPRESS_ is automatically extracted and made available in Cypress.
    2. Config Object: Define additional variables directly in the env object within your cypress.config.js file.
    3. Node.js process.env: Use the setupNodeEvents function in cypress.config.js to manually copy variables from process.env into the Cypress environment.
    4. Dotenv: Use the dotenv package within cypress.config.js to load variables from a .env file into process.env before they are processed by Cypress.
  7. Open the Cypress App for an example project

    master

    To open the Cypress Test Runner GUI for a specific example, navigate to that project's directory, start its local development server in the background, and then run the cypress:open script.

    Example for testing-dom__drag-drop:

    1. Navigate to the directory.
    2. Start the local server using npm start &.
    3. Run npm run cypress:open.
    cd ./examples/testing-dom__drag-drop
    # start local server
    npm start &
    # open Cypress App
    npm run cypress:open
  8. Run tests in specific browsers

    master
    You can execute tests in specific browsers using test:ci:* NPM scripts. These scripts are designed to find all projects within example subfolders that have a matching script and will automatically start the necessary servers. Available browser scripts include brave, firefox, and chrome.