Osura Hettiarachchi

Upcoming changes to component testing in Cypress.io

Changes to component testing in cypress blog cover image
Please note that this is a blog post that has been copied from an external source. All rights of the blog content is held by Lachlan Miller

Summary

Cypress 7 introduced the alpha version of a new testing type '‐ the first since Cypress' inception '‐ Component Testing. Cypress 10 brought a number of updates and improvements, marking the beta version of Component Testing.
Early next week, we will be releasing Cypress 11. With this release, we are excited to announce that we are removing the beta tag. Cypress Component Testing has a stable API, and is now considered generally available.
As part of Cypress 11, we are making some small changes to the mount API, the main way you render components. These changes lay the foundation for our officially supported libraries (React, Vue, Angular, and Next.js), as well as for third party integrations and future official adapters. This will let you use Cypress with the exact same API across any component library or framework, without needing to learn any new syntax.
In this post I will outline the changes we are making, why we are making them, and how you can migrate to Cypress 11 when it is released. Migrating should be straightforward for the majority of code bases.


Changes to Mounting Options

Cypress Mount Adapters take two parameters. The first is your component. The second is the Mounting Options. Each framework has some specific mounting options ‐ for example, Svelte Mounting Options contain a props property, and Vue's contain a data property. Neither of these is necessary for React ‐ idiomatically, you pass props using JSX, so a props property isn't necessary. Some frameworks Mounting Options also supported some additional properties which we call Style Options. Those are:

  • cssFile, cssFiles
  • style, styles
  • stylesheet, stylesheets

We've decided to remove these options with the goal of providing a consistent experience across all frameworks, and also minimizing the number of ways to do the same thing.

We recommend writing test specific styles in a separate file, which can then be imported into either:

  • Your supportFile (for styles shared by many tests)
  • Your spec file (for styles only used in one or two tests)

This has an additional benefit: by writing styles in a separate file, you can use the same preprocessor pipeline as your components. Styling options were injected as-is, without any transformations applied, which sometimes led to differences in test code vs production code.

An example migration looks like this:


Before (Cypress 10)

/** Card.cy.jsx */
    import { mount } from 'cypress/react'
    import { Card } from './Card'

    it('renders some content', () => {
        cy.mount(<Card title=”title” />, {
            styles: `
                .card { width: 100px; }
            `,
            stylesheets: ['https://cdn.jsdelivr.net/npm/bootstrap@5.2.2/dist/css/bootstrap.min.css']
        })
    })