Cypress Component Testing is a feature built into Cypress (since version 10) that lets you mount individual UI components \u2014 React, Vue, Angular, or Svelte \u2014 directly in a real browser and test them without running your full application. Unlike jsdom-based tools such as Jest + React Testing Library, Cypress renders your component in an actual Chrome or Firefox browser, giving you real CSS, real layout, and real user interaction behavior.<\/p>\n\n\n\n
You’ve written the component. The unit tests pass. You push to staging \u2014 and the dropdown doesn’t open. The button is there, the click handler is there, but something about the actual browser behavior is off.<\/p>\n\n\n\n
This is the gap that Cypress component testing was built to close. Not your whole app. Not a mocked DOM. A real browser, your real component, and tests you can actually watch run.<\/p>\n\n\n\n
In this tutorial, you’ll learn what Cypress Component Testing is, how it differs from both E2E tests and jsdom-based unit tests, and how to write your first component test \u2014 step by step. We’ll use React, but the approach is the same for Vue and Angular.<\/p>\n\n\n\n
Cypress Component Testing is a testing mode built into Cypress that lets you import and mount individual UI components in a real browser, interact with them, and assert on their behavior \u2014 without spinning up your full application.<\/p>\n\n\n\n
It was introduced in Cypress 7 as an experimental feature and became stable in Cypress 10 (released mid-2022). It supports React, Vue 3, Angular, and Svelte through official framework adapters.<\/p>\n\n\n\n The key thing that sets Cypress Component Testing apart from jsdom-based tools (Jest, Vitest + RTL) is the runtime: your component runs in a real browser. Real CSS renders. Real layout applies. Real scroll behavior happens. This catches an entire class of bugs that jsdom silently misses.<\/p>\n\n\n\n There are now three main options for testing UI components. Here’s how they actually compare:<\/p>\n\n\n\n When you run a Cypress component test, here’s what actually happens:<\/p>\n\n\n\n There’s no routing, no authentication, no network calls (unless you explicitly stub them). Just your component, rendered in isolation, in a real browser.<\/p>\n\n\n\n The Cypress Launchpad will open. Select ‘Component Testing’, then choose your framework (React) and bundler (Vite or webpack). Cypress auto-generates a cypress.config.js with the correct settings.<\/p>\n\n\n\n Your generated cypress.config.js should look something like this:<\/p>\n\n\n\n Cypress also generates a cypress\/support\/component.js file. For React, add the mount command import:<\/p>\n\n\n\n Let’s say you have a Button component that accepts a label prop and calls an onClick handler:<\/p>\n\n\n\n Here’s the Cypress component test for it:<\/p>\n\n\n\n A few things worth noticing:<\/p>\n\n\n\n The Cypress runner opens, shows your component test files, and lets you click through each spec. You’ll see your Button component rendered in the preview pane on the right \u2014 live, in a real browser.<\/p>\n\n\n\n Cypress’s command API works exactly the same in component tests as in E2E tests. You can click, type, focus, blur, select, scroll \u2014 all the real browser actions you’d expect.<\/p>\n\n\n\n One area where Cypress Component Testing really shines is testing the full range of prop combinations \u2014 including the ones that only cause problems in the browser.<\/p>\n\n\n\n Here’s a concrete example of why the real-browser runtime matters.<\/p>\n\n\n\n Say you have a Modal component. Your Jest tests confirm it renders, shows the title, and closes when the close button is clicked. All green. You ship.<\/p>\n\n\n\n In production, users report the modal is there \u2014 but they can’t see it. The z-index on the modal is 100, but a parent container somewhere in the app has an isolated stacking context (triggered by transform: translateZ(0)). The modal renders behind it. Invisible.<\/p>\n\n\n\n Jest never catches this. There’s no CSS in jsdom. Cypress Component Testing catches it the first time you mount the modal inside a wrapper that mimics your app’s layout \u2014 because real CSS applies, real stacking contexts form, and real visibility is computed.<\/p>\n\n\n\n [HUMAN EDITOR: Replace with a real z-index or CSS stacking bug your team actually encountered. Include the component name, the CSS property that caused it, and how long it took to diagnose in production vs. how long it takes to catch in a Cypress component test now. This is the highest-value E-E-A-T addition in this article.]<\/p>\n\n\n\n The gap between ‘tests pass’ and ‘works in the browser’ is real \u2014 and it’s wider than most testing setups account for. CSS stacking contexts, scroll containers, focus management, and real event bubbling all behave differently in a real browser than in jsdom.<\/p>\n\n\n\n Cypress Component Testing fills that gap without forcing you to run your entire app. You get browser fidelity at component-test speed. And you get to watch your components actually render while the tests run \u2014 which, honestly, changes how you think about what you’re testing.<\/p>\n\n\n\n Pick one component. Mount it. Assert on what a user would actually see. That’s all it takes to start.<\/p>\n\n\n\n Head to the GUVI blog for more hands-on guides on frontend testing, Cypress, and building a complete quality strategy for your UI.<\/p>\n\n\n\n Cypress Component Testing is a mode built into Cypress 10+ that lets you mount and test individual UI components in a real browser, without running your full application. It supports React, Vue, Angular, and Svelte through official framework adapters.<\/p>\n\n<\/div>\n<\/div>\n Yes. E2E tests visit a full running application via a URL and test complete user flows. Component tests mount a single component in isolation \u2014 no server, no routing, no authentication. Component tests are faster and more targeted; E2E tests are more realistic. Most teams use both.<\/p>\n\n<\/div>\n<\/div>\n No \u2014 and it shouldn’t. Jest and React Testing Library are excellent for testing logic, hooks, and accessibility in a fast feedback loop. Cypress Component Testing adds value specifically for rendering fidelity, real browser interactions, and visual state. Use both: Jest for logic, Cypress for rendering.<\/p>\n\n<\/div>\n<\/div>\n Yes. Cypress has official support for React (17 and 18), Vue 3, Angular 12+, and Svelte. You select your framework during the Cypress setup wizard, and it configures the mount command and dev server automatically.<\/p>\n\n<\/div>\n<\/div>\n Run ‘npx cypress run –component’ in your CI pipeline. Cypress runs in headless Chrome or Electron by default. Most CI platforms (GitHub Actions, GitLab CI, CircleCI) support this without additional configuration \u2014 just make sure Node.js and the necessary browser dependencies are available.<\/p>\n\n<\/div>\n<\/div>\n cy.mount() is the Cypress command that renders a component into the test browser. You pass it JSX (for React) or a component definition (for Vue\/Angular) along with any props. It’s equivalent to render() in React Testing Library, but the output renders in a real browser instead of jsdom.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":" Cypress Component Testing is a feature built into Cypress (since version 10) that lets you mount individual UI components \u2014 React, Vue, Angular, or Svelte \u2014 directly in a real browser and test them without running your full application. Unlike jsdom-based tools such as Jest + React Testing Library, Cypress renders your component in an […]<\/p>\n","protected":false},"author":63,"featured_media":126929,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[706],"tags":[],"views":"16","authorinfo":{"name":"Vishalini Devarajan","url":"https:\/\/www.guvi.in\/blog\/author\/vishalini\/"},"thumbnailURL":"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2026\/07\/Cypress-Component-Testing-300x116.webp","_links":{"self":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/124377"}],"collection":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/users\/63"}],"replies":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/comments?post=124377"}],"version-history":[{"count":5,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/124377\/revisions"}],"predecessor-version":[{"id":125369,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/124377\/revisions\/125369"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media\/126929"}],"wp:attachment":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media?parent=124377"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/categories?post=124377"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/tags?post=124377"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\ud83d\udcca Data Point <\/strong>Cypress is the most widely used JavaScript E2E testing tool, with over 46,000 GitHub stars and 5 million weekly npm downloads as of early 2026. Component testing is now one of its fastest-growing feature areas. [HUMAN EDITOR: Verify current npm download figures and star count before publishing]<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Cypress Component Testing vs E2E Testing vs Jest + RTL<\/strong><\/h2>\n\n\n\n
<\/td> Jest + RTL<\/strong><\/td> Cypress E2E<\/strong><\/td> Cypress Component Testing<\/strong><\/td><\/tr> Runtime<\/td> jsdom (simulated)<\/td> Real browser<\/td> Real browser<\/td><\/tr> Tests full app?<\/td> No<\/td> Yes<\/td> No<\/td><\/tr> Needs running server?<\/td> No<\/td> Yes<\/td> No<\/td><\/tr> Real CSS\/layout?<\/td> No<\/td> Yes<\/td> Yes<\/td><\/tr> Speed<\/td> Very fast<\/td> Slow<\/td> Fast<\/td><\/tr> Best for<\/td> Logic, accessibility, output<\/td> Full flows, routing, auth<\/td> Component behavior, interactions, visual state<\/td><\/tr> Setup complexity<\/td> Low<\/td> Medium<\/td> Low-Medium<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n \ud83d\udca1 Contrarian Take <\/strong>A lot of teams treat Cypress Component Testing as ‘Jest but in a browser.’ That undersells it. The real value isn’t speed \u2014 it’s fidelity. When a component only breaks because of a CSS specificity conflict or a scroll container, Jest will never catch it. Cypress will. The question isn’t which tool is better; it’s which failure modes matter most to you.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n How Does Cypress Component Testing Work?<\/strong><\/h2>\n\n\n\n
\n
\ud83d\udca1 Pro Tip <\/strong>The Cypress component testing preview pane is one of the most useful debugging tools in frontend development. You can see exactly what your component looks like at every step of the test \u2014 including the state it’s in when an assertion fails. Time-travel debugging for your components.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Step-by-Step: Setting Up Cypress Component Testing in a React Project<\/strong><\/h2>\n\n\n\n
Prerequisites<\/strong><\/h3>\n\n\n\n
\n
Step 1 \u2014 Install Cypress<\/strong><\/h3>\n\n\n\n
npm install –save-dev cypress<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Step 2 \u2014 Open Cypress and Choose Component Testing<\/strong><\/h3>\n\n\n\n
npx cypress open<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n \u2705 Best Practice <\/strong>Let the Cypress setup wizard run fully before editing anything. It detects your framework and bundler automatically and writes a working config. Manually editing the config before the wizard finishes is a common source of first-run failures.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Step 3 \u2014 Confirm Your Config<\/strong><\/h3>\n\n\n\n
import { defineConfig } from ‘cypress’;
export default defineConfig({ component: { devServer: { framework: ‘react’, bundler: ‘vite’, }, },});<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nStep 4 \u2014 Create the Support File<\/strong><\/h3>\n\n\n\n
import { mount } from ‘cypress\/react18’;
Cypress.Commands.add(‘mount’, mount);<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n\u26a0\ufe0f Warning <\/strong>Use cypress\/react18 if you’re on React 18. Use cypress\/react for React 17 and below. Mixing these causes a silent failure where components render but hooks behave incorrectly.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Writing Your First Cypress Component Test<\/strong><\/h2>\n\n\n\n
\/\/ src\/components\/Button.jsxexport function Button({ label, onClick }) { return ( <button onClick={onClick} className=’btn’> {label} <\/button> );}<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n \/\/ src\/components\/Button.cy.jsximport { Button } from ‘.\/Button’;
describe(‘Button’, () => { it(‘renders the label’, () => { cy.mount(<Button label=’Submit’ onClick={cy.stub()} \/>); cy.get(‘button’).should(‘contain.text’, ‘Submit’); });
it(‘calls onClick when clicked’, () => { const handleClick = cy.stub().as(‘clickHandler’); cy.mount(<Button label=’Submit’ onClick={handleClick} \/>); cy.get(‘button’).click(); cy.get(‘@clickHandler’).should(‘have.been.calledOnce’); });});<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n\n
Run the Component Tests<\/strong><\/h3>\n\n\n\n
npx cypress open –component<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Testing User Interactions and Events<\/strong><\/h2>\n\n\n\n
\/\/ Testing a search inputit(‘calls onSearch when the user types’, () => { const onSearch = cy.stub().as(‘searchHandler’); cy.mount(<SearchInput onSearch={onSearch} \/>);
cy.get(‘input’).type(‘cypress’); cy.get(‘@searchHandler’).should(‘have.been.calledWith’, ‘cypress’);});
\/\/ Testing a dropdownit(‘shows options when opened’, () => { cy.mount(<Dropdown options={[‘React’, ‘Vue’, ‘Angular’]} \/>); cy.get(‘[data-testid=dropdown-trigger]’).click(); cy.get(‘[data-testid=dropdown-menu]’).should(‘be.visible’); cy.contains(‘Vue’).should(‘be.visible’);});<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n\u2705 Best Practice <\/strong>Use data-testid attributes as your primary selectors in component tests \u2014 not class names or text. Class names change with styling refactors. Text changes with copy edits. data-testid is an explicit test contract that doesn’t break for the wrong reasons.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Testing Props, Slots, and Edge Cases<\/strong><\/h2>\n\n\n\n
\/\/ Test the empty stateit(‘shows empty state when items array is empty’, () => { cy.mount(<ItemList items={[]} \/>); cy.get(‘[data-testid=empty-state]’).should(‘be.visible’); cy.get(‘[data-testid=item]’).should(‘not.exist’);});
\/\/ Test a loading stateit(‘shows a spinner while loading’, () => { cy.mount(<ItemList items={[]} loading={true} \/>); cy.get(‘[data-testid=spinner]’).should(‘be.visible’);});
\/\/ Test with many items (layout stress test)it(‘renders 100 items without layout breakage’, () => { const items = Array.from({ length: 100 }, (_, i) => ({ id: i, name: `Item ${i}` })); cy.mount(<ItemList items={items} \/>); cy.get(‘[data-testid=item]’).should(‘have.length’, 100);});<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n\ud83d\udca1 Pro Tip <\/strong>The 100-item layout stress test is something jsdom-based tests simply can’t do meaningfully. In jsdom, there’s no real rendering \u2014 100 items look the same as 1. In Cypress, you can scroll the list, confirm items are visible in the viewport, and catch overflow or truncation bugs that only appear with real data volumes.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Real-World Scenario: Catching a CSS-Dependent Bug<\/strong><\/h2>\n\n\n\n
Pros and Cons of Cypress Component Testing<\/strong><\/h2>\n\n\n\n
Pros<\/strong><\/td> Cons<\/strong><\/td><\/tr> Tests run in a real browser \u2014 real CSS, real layout<\/td> Slower than Jest\/Vitest unit tests (though faster than E2E)<\/td><\/tr> Same Cypress API you already know from E2E tests<\/td> Requires Cypress 10+ \u2014 older projects need an upgrade<\/td><\/tr> Live visual preview of the component while tests run<\/td> No built-in visual regression (need Percy or Applitools add-on)<\/td><\/tr> Works with React, Vue, Angular, Svelte out of the box<\/td> CI setup needs a browser environment (Electron or Chrome headless)<\/td><\/tr> Time-travel debugging \u2014 see component state at each step<\/td> Doesn’t test routing, auth, or multi-page flows (that’s E2E’s job)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Best Practices for Cypress Component Testing<\/strong><\/h2>\n\n\n\n
\n
\u2705 Best Practice <\/strong>Start by writing Cypress component tests for your most bug-prone or most complex components first \u2014 not by trying to achieve 100% coverage of everything. Complex form components, multi-state modals, and drag-and-drop interfaces are where component tests deliver the most immediate value.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Key Takeaways<\/strong><\/h2>\n\n\n\n
\n
\u27a1\ufe0f What to Do Next <\/strong>1. Install Cypress in your project if you haven’t already. 2. Run ‘npx cypress open’ and select Component Testing. 3. Pick your most complex or most bug-prone component. 4. Write one test that covers its most important interaction. 5. Run it \u2014 watch the component render in the preview pane. Then read the related articles below to build a full frontend testing strategy.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Conclusion<\/strong><\/h2>\n\n\n\n
Frequently Asked Questions<\/strong><\/h2>\n\n\n
1. What is Cypress Component Testing?<\/strong><\/h3>\n
2. Is Cypress Component Testing different from Cypress E2E testing?<\/strong><\/h3>\n
3. Does Cypress Component Testing replace Jest and React Testing Library?<\/strong><\/h3>\n
4. Can I use Cypress Component Testing with Vue or Angular?<\/strong><\/h3>\n
5. How do I run Cypress component tests in CI?<\/strong><\/h3>\n
6. What is cy.mount() in Cypress?<\/strong><\/h3>\n