Workflow:Cypress io Cypress Component Test Execution
| Knowledge Sources | |
|---|---|
| Domains | Testing, Component_Testing, Frontend_Development |
| Last Updated | 2026-02-12 00:00 GMT |
Overview
End-to-end process for testing individual UI components in isolation using Cypress Component Testing, from framework detection through component mounting, interaction, and assertion.
Description
This workflow covers testing individual frontend components (React, Vue, Angular, Svelte) without requiring a running application server. Cypress mounts components directly in a real browser using framework-specific mount utilities, enabling developers to test component behavior, rendering, and interactions in isolation. The component test dev server (powered by Vite or Webpack) compiles and serves components on demand, providing fast feedback loops during development.
Key outputs:
- Component-level test results with pass/fail status
- Visual confirmation of component rendering in the Cypress UI
- Isolated verification of props, events, slots, and state transitions
Usage
Execute this workflow when you need to test UI components independently of the full application. This is appropriate for validating component behavior across different prop combinations, user interactions, and edge cases without the overhead of full application setup. Use this for design system components, form elements, data display widgets, and any reusable UI building blocks.
Execution Steps
Step 1: Configure Component Testing
Enable component testing in the Cypress configuration file by specifying the component testing block. The scaffold-config package detects the project's frontend framework and bundler automatically. The devServer callback configures the component dev server with the appropriate framework adapter and bundler integration.
Key considerations:
- Framework detection identifies React, Vue, Angular, Svelte, and their associated bundlers
- The devServer option accepts a framework/bundler pair or a custom dev server function
- Component testing uses a separate specPattern from E2E (default: **/*.cy.{js,ts,jsx,tsx})
- The supportFile for component tests is distinct from the E2E support file
Step 2: Write Component Tests
Author test files that import components and mount them using the framework-specific mount utility provided by Cypress. Each test mounts a component with specific props, slots, or context, then uses Cypress commands to interact with and assert on the rendered output.
Key considerations:
- Mount utilities are imported from cypress/react, cypress/vue, cypress/angular, or cypress/svelte
- The mount function accepts the component and an options object for props, slots, and wrappers
- Components render inside the Cypress iframe with full CSS and JavaScript support
- Custom mount wrappers can provide context providers, routers, or store bindings
Step 3: Start Component Dev Server
Launch the component testing dev server which compiles components on demand using the project's existing build toolchain. The dev server integrates with Vite or Webpack to handle module resolution, transpilation, and hot module replacement. Cypress communicates with the dev server to request component bundles for each test.
Key considerations:
- The dev server reuses the project's existing Vite or Webpack configuration
- Framework-specific plugins handle JSX/TSX compilation and template processing
- CSS modules, Tailwind, and other preprocessors work transparently
- The dev server runs on a dynamic port and communicates with the Cypress server
Step 4: Mount and Render Components
For each test, the mount utility creates an isolated component instance in the browser. The component renders with the provided props and context, and the resulting DOM is available for Cypress commands to query and interact with. Each test gets a clean component instance.
Key considerations:
- Components are mounted into a dedicated container element in the Cypress iframe
- Each test unmounts the previous component before mounting a new one
- Style isolation ensures component styles do not leak between tests
- The browser provides a real rendering environment (not JSDOM)
Step 5: Execute Assertions and Interactions
Use standard Cypress commands to interact with the mounted component and verify its behavior. Click buttons, type into inputs, trigger events, and assert on the resulting DOM state. The Cypress command log displays all interactions for debugging.
Key considerations:
- All standard Cypress commands (cy.get, cy.click, cy.type, cy.should) work with mounted components
- Component events can be spied on using cy.spy() passed as event handler props
- Network requests from components can be intercepted with cy.intercept()
- Visual snapshots can capture component rendering states
Step 6: Review Results
After test execution, review pass/fail results in the Cypress UI or CI output. Component test results follow the same reporting format as E2E tests, with command logs, error messages, and optional screenshots on failure.
Key considerations:
- Results integrate with the same reporters used for E2E testing
- Screenshots capture the component's rendered state on failure
- The Cypress UI shows real-time component rendering during interactive runs
- Results can be recorded to Cypress Cloud alongside E2E test results