Component test
A test that renders and uses one UI component by itself, so you can check its behavior without starting the whole application.
See it
What it is
A component test renders one UI component with the small amount of context it needs, then interacts with it and checks what a user can see or do. A React button might get props and a router wrapper, but not the whole application, production server, or real payment service. React Testing Library, Vue Test Utils, and Storybook interaction tests all work at this layer.
Reach for one when the behavior belongs to the component: a menu opens from the keyboard, validation text appears after blur, or a disabled button cannot submit. Query by role, label, and visible name so the test follows the same interface a person or assistive technology uses. That is React Testing Library's guiding rule: the more your tests resemble the way your software is used, the more confidence they can give you.
Gotcha: component tests become brittle when they inspect class names, private state, or a child component's implementation. They can also miss broken application wiring. A form that behaves perfectly with a fake callback still needs an integration or end-to-end test proving the real callback saves anything.
Ask AI for it
Write Vitest component tests for the <ComponentName> React component using React Testing Library and @testing-library/user-event. Render only the component plus the router, context, or store providers it actually requires. Cover its default state, keyboard interaction, one validation or error state, and the callback it owns. Query with getByRole, getByLabelText, and accessible names, never CSS classes or implementation state, and use findByRole for asynchronous UI changes.