Cypress Component Testing

What Is Component Testing?

Cypress component testing uses your project's own build tooling (Vite, webpack, or a supported framework preset) to mount a single component in a real browser, in isolation from the rest of your application, then runs the exact same Cypress commands and assertions you already know from E2E testing against it.

This gives you E2E-testing ergonomics (a real browser, real DOM, real user interactions) at the speed and isolation level of a unit test, without needing a full running application or backend.

import Button from './Button';

it('calls onClick when clicked', () => {
  const onClick = cy.stub().as('onClick');
  cy.mount(<Button onClick={onClick}>Save</Button>);
  cy.get('button').click();
  cy.get('@onClick').should('have.been.calledOnce');
});

cy.mount() renders just this one component; there is no full page, router, or backend involved.

E2E vs Component Testing at a Glance

E2E:       cy.visit('/page') -> full app, real routing, real (or stubbed) backend
Component: cy.mount(<Component />) -> just this component, in isolation

• E2E testing verifies full user flows across pages and real (or stubbed) backend integration.
• Component testing verifies a single component's rendering, props, events, and internal state.
• Both use the same core Cypress commands: .get(), .click(), .should(), and so on.
• Component testing requires a small amount of framework-specific configuration (a dev server, mount function).

Component vs E2E Testing Cheat Sheet

Choosing the right testing type for a given scenario.

Why Component Tests Run Faster Than E2E Tests

Because a component test never loads a full application, routes, or a backend, it avoids most of the overhead that makes E2E tests comparatively slow: full page loads, authentication, and network round trips. This lets teams write many more granular tests without a slow overall suite.

Setting Up Component Testing

Running npx cypress open and choosing "Component Testing" during setup walks through detecting your framework and bundler automatically, generating a component block in cypress.config.js with the correct dev server configuration.

// cypress.config.js
export default defineConfig({
  component: {
    devServer: {
      framework: 'react',
      bundler: 'vite',
    },
  },
});

Common Mistakes

• Trying to test full navigation flows using component testing, which has no real router or multi-page context by default.
• Using component testing exclusively and dropping E2E coverage entirely, losing confidence in real integration.
• Not realizing component tests still run in a real browser, they are not the same as framework-level unit tests.
• Forgetting to configure the correct bundler/framework combination during setup, causing mount errors.

Key Takeaways

• Component testing mounts a single component in isolation, using your project's real build tooling.
• It offers E2E-like ergonomics at closer to unit-test speed and isolation.
• E2E and component testing are complementary, not replacements for one another.
• Setup requires framework/bundler-specific configuration in cypress.config.js.