Component testing is the practice of rendering a single UI component on its own, driving it the way a user would, and asserting on what it displays and emits. It sits between unit testing, which calls functions with no rendering at all, and integration testing, which wires several parts together.

The distinction that matters: a unit test asks whether the logic is right, and a component test asks whether the thing a person sees and clicks is right.

Where does component testing sit between unit and E2E tests?

Four layers, each answering a different question.

Layer	What It Runs	What It Answers	Typical Speed
Unit	One function or class	Is the logic correct	Milliseconds
Component	One rendered component	Does it render and respond correctly	Tens of milliseconds
Integration	Several parts wired together	Do they work when connected	Seconds
End to end	The whole application	Does the user journey complete	Tens of seconds

Teams argue about these boundaries constantly and the argument is not pedantic. A r/ExperiencedDevs thread titled "Unit vs integration tests, what's your definition?" collected 49 comments without reaching agreement, and a r/QualityAssurance thread asking whether there is any reason to write test cases for components that already have unit tests is the same confusion from the QA side.

Worth holding onto: component testing exists because a component can pass every unit test and still render nothing.

What does a component test actually catch?

Things a unit test structurally cannot see.

Rendering failures. A prop arrives as undefined, the component throws during render, and the function it wraps was perfectly correct.

Conditional display. The empty state, the loading state, the error state. Most components have four or five, and most suites test one.

Interaction wiring. The button exists, looks right, and calls nothing, because the handler was never bound.

Accessibility basics. The control has no label, no role, or a focus order that traps the keyboard.

Prop contract breaks. A parent renames a prop and the child silently renders a default forever.

Component testing vs unit testing: what is the real difference?

The honest answer is that the boundary is about rendering, not about size.

A unit test for a form validator imports the function and asserts on return values. A component test for the same form mounts it, types an invalid email, and asserts that the error message appears on screen. Both test the same rule. Only one proves a user would see the result.

That is also why the two are complements rather than substitutes. Validation edge cases belong in fast unit tests, because there might be thirty of them. The fact that one failure renders visibly belongs in a component test, because one case proves the wiring.

The cost question comes up every time. A r/reactjs thread bluntly titled "React testing library a pain in the ass?" and another on making those tests 43% faster, at 47 votes, are both symptoms of suites where the component layer grew without anyone deciding what belonged in it.

What does a component test look like?

A worked example makes the boundary concrete. Take a PriceTag component that takes an amount and a currency and shows a discount badge when a sale price is passed.

The unit test covers the formatting function: given 1999 and USD, it returns $19.99. Thirty of those run in a few milliseconds and none of them render anything.

The component test mounts PriceTag four times:

With a plain price, and asserts the formatted amount is visible.
With a sale price, and asserts both the original price and the badge appear.
With a null amount, and asserts the component renders a placeholder rather than throwing.
With a very long currency string, and asserts the layout does not clip.

Case three is the one that matters. A null amount is the bug that reaches production, it passes every unit test on the formatter, and it is invisible until something renders.

The integration test would be the product page fetching a real price from the pricing service and passing it down. The end-to-end test would be a user adding that product to a basket and checking out. Four tests, four questions, and only one of them belongs at the component layer.

Which tools do component testing?

Four serious options, and they differ mainly in where the component renders.

Cypress Component Testing

Cypress mounts components directly in a real browser rather than a simulated DOM, so each one renders visually during the run and browser DevTools work for inspecting and debugging exactly as in development.

Official mounting libraries cover React, Angular, Vue and Svelte, with community plugins for Qwik and Lit. The setting that matters is component.devServer in the Cypress config, which tells Cypress which UI framework and bundler to use.

The structural advantage is that component tests live in the same project as the end-to-end tests, so results, flake patterns and coverage arrive in one view rather than two.

Playwright component testing

Playwright takes a leaner route. A component test is a regular Playwright test running against a small story gallery page served by your own dev server, with no dedicated component-testing runtime, no bundler integration and no extra packages. The built-in mount() fixture drives everything.

Check your version before you follow an older tutorial. The experimental @playwright/experimental-ct-react, -ct-react17 and -ct-vue packages have been removed and are no longer published. Teams still on them should stay on Playwright 1.62 until they have migrated.

Storybook

Storybook turns stories you already wrote into tests through the play function and interaction tests. On a Vite project the Vitest addon runs them, installed with npx storybook add @storybook/addon-vitest, with the test-runner as the fallback elsewhere.

This is the cheapest option for teams who already maintain a component library, because the test cases exist already.

Testing Library

The most widely used approach and the most opinionated. It renders into a simulated DOM and pushes you to query by accessible role and text rather than by test ID, which makes tests resemble how a user finds things.

The cost is realism. A simulated DOM is fast and is not a browser, so layout, real focus behaviour and anything depending on actual rendering stay invisible.

Tool	Renders In	Best When
Cypress CT	Real browser	You already run Cypress E2E and want one quality signal
Playwright CT	Real browser via your dev server	You run Playwright and want no extra tooling
Storybook	Your Storybook instance	A component library already exists
Testing Library	Simulated DOM	Speed matters more than rendering fidelity

When is component testing worth the effort?

Yes, when the component is reused. A design system button tested once protects every screen that uses it.

Yes, when the component has many states. Loading, empty, error, partial and success is five tests at the component layer and five very slow tests at the end-to-end layer.

Yes, when end-to-end tests keep failing for UI reasons. Pushing those assertions down a layer makes them faster and more precise.

No, when the component is a one-off layout wrapper. It has no logic and no states, so the test asserts that a div exists.

No, when the real risk is the journey. A checkout that fails between the cart and the payment provider is not a component problem, and no amount of component coverage will find it.

Maybe, when the team is small. The honest version of this answer is that someone has to maintain the layer. A r/QualityAssurance thread asking who actually writes the unit and integration tests drew 24 votes and 35 comments, and the recurring theme is that ownership decides whether a layer survives contact with a deadline.

That last point is the common trap. A r/ExperiencedDevs thread on frustrations with an end-to-end-only approach makes the opposite case well, and both failure modes come from treating one layer as the whole strategy.

How does component testing apply to mobile apps?

Less neatly than on the web, and it is worth being clear about why.

Component testing as a practice grew up around web component frameworks with a mount function and a dev server. The native mobile equivalents exist, through Espresso for Android views and XCUITest for iOS, but they are heavier and the isolation is less clean, because a native view usually needs more of the application alive around it.

In practice most mobile teams run unit tests below and end-to-end tests above, with a thin component layer in the middle for anything genuinely reusable. Cross-platform teams get closer to the web model, since a React Native component can be mounted much like a React one.

Where agent-based end-to-end testing fits: it does not replace this layer. Autosana works at the journey layer, driving a running app the way a person would, which is the layer above component testing rather than a substitute for it. A team with no component tests and good end-to-end coverage will find the failures later and more slowly. A team with excellent component tests and no end-to-end coverage will ship a product where every part works and the journey does not.

Conclusion

Component testing earns its place by catching the defects that live between logic and journey: the state that renders blank, the handler that was never wired, the label nobody added.

Decide what belongs there deliberately. The suites that go wrong are the ones where the component layer grew by accident, absorbed work that belonged in unit tests, and became slow enough that people started skipping it.

Frequently asked questions

What is component testing in software testing?

Rendering a single component on its own, interacting with it as a user would, and asserting on what it displays and emits. It is distinct from unit testing because the component actually renders, and distinct from integration testing because nothing else is wired to it.

What is the difference between component testing and unit testing?

Rendering. A unit test calls a function and checks the return value. A component test mounts the component, drives it, and checks what appears on screen. The same validation rule can be covered by both, and only the component test proves a user would see the result.

Is component testing the same as integration testing?

No. Component testing isolates one component. Integration testing connects several parts and checks they work together. A component test with three real children wired in has quietly become a narrow integration test, which is fine as long as everyone knows.

Which tool is best for component testing?

Whichever matches the rest of your stack. Cypress and Playwright both mount in a real browser and are the natural choice if you already run them for end-to-end tests. Storybook is cheapest if a component library exists. Testing Library is fastest and renders into a simulated DOM rather than a browser.

Does Playwright still support component testing?

Yes, through the built-in mount() fixture against a story gallery page served by your own dev server. The older experimental @playwright/experimental-ct-* packages have been removed and are no longer published, so tutorials referencing them are out of date.

How many component tests should a team write?

Enough to cover each distinct state of each reusable component, and no more. The signal that the layer has grown too far is duplication: if a component test and a unit test both exist for the same validation rule, one of them is paying rent for nothing.