🧩 Component Testing

Component Testing: Component Testing means running a single React/Vue/Angular component in a real browser in isolation — like mounting an aircraft engine on a factory test stand

Component Testing means running a single React/Vue/Angular component in a real browser in isolation — like mounting an aircraft engine on a factory test stand before rolling the plane out to the runway: the fuselage, cockpit, and fuel system are completely absent; you verify only whether the engine itself performs within its own parameters. But if E2E tests already run in the browser, why invest in a separate Component Testing infrastructure? Because triggering a component's edge cases (error state, empty state, accessibility behavior) through a full E2E flow is expensive — you can't ask "does the payment button show a tooltip when disabled?" without first navigating through a three-page login flow. In Java, Spring's @WebMvcTest boots only the MVC layer and mocks the service and repository beans; Component Testing is the browser equivalent: only that layer spins up, so the feedback loop is fast. The critical QA risk: jsdom-based unit tests (Jest + RTL) don't run a real browser DOM and miss CSS, layout, and scroll bugs; Component Testing runs in Chromium and catches that entire class of visual defects before they ever reach an E2E suite.

The cy.mount() command renders the component in a real browser (not a fake DOM like jsdom). As Cypress's own docs put it, "you test components exactly as they will behave for your users" — rendering is real, retry-ability and auto-waiting are built-in, and you never need to write waitFor() or act().

cy.mount() — React Counter Example

Micro Lab: Cypress — Writing assertions

Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.

Step by Step: Cypress — Writing assertions

Determine what to assert: visibility / text / CSS / attribute

Verify element is visible with .should("be.visible")

Check text content with .should("contain.text", "Login Successful")

Verify attribute with .should("have.attr", "disabled") or "href"

When test fails, read Cypress error: expected X to ... but got Y

What is the Cypress assertion writing and verification order?

In Mockito, @Mock fakes out external dependencies (PaymentGateway) so you isolate just CartService — without booting the whole Spring context. cy.mount() follows the same philosophy, isolating a single component without launching the entire React/Vue app.

Component Testing doesn't REPLACE E2E tests — they complement each other: component tests give fast/isolated unit-level verification, E2E tests verify real user flows.