Component Tests and Snapshot Tests: A Small Application Fragment
A unit test can check a rule well, but sometimes the bug does not live in one function.
A form validates a field correctly, but the button becomes enabled too early.
A component renders an empty state, but loses the error message after the second click.
A mapper works, but after composition with formatting the output has a shape the rest of the application does not expect.
That is where the component test belongs.
What kind of test this is
Component test checks a small part of the application as a whole.
The unit can be:
UI component
form
widget
small domain module
parser with a public API
adapter with a local fake
This is not the full system.
It is a fragment larger than one function, but still small enough for fast diagnosis.
In frontend code a component test usually renders a component with props, state, a provider, or a simple fake dependency.
In backend code a similar role can be played by testing a small module through its public API, without a real database and without starting a server.
How it differs from a unit test
A unit test checks a decision in code.
A component test checks cooperation between several decisions in a small fragment.
unit test
a 100% discount does not produce a negative price
component test
the form shows price 0, blocks payment, and shows a message
When a unit test fails, the broken rule is usually clear.
When a component test fails, a fragment of behavior broke, but the cause may sit in several places.
That is still cheap.
You do not need to start the whole application, log a user in, and walk through a real E2E path.
Snapshot tests
Snapshot test records output and compares it with the next run.
The output can be:
component tree
HTML
JSON
text data format
generated manifest
A snapshot does not say behavior is correct.
It says:
the output changed compared with the accepted version
That can be useful when the output is large and a change is easy to miss in review.
It is also risky.
If the team updates snapshots with a command and does not read the diff, the snapshot test becomes noise.
What happens when they are missing
Without component tests, small composition bugs escape to E2E.
E2E starts checking whether a button is disabled, whether a message appeared, or whether form state was cleared.
Those are real behaviors, but they are too cheap to check only through the full system path.
Without snapshots, an output change can pass unnoticed.
That matters for generated schemas, manifests, configuration, or large UI fragments.
But a snapshot does not replace an assertion.
If the important thing is that a button saves an order, an assertion on behavior is better than a snapshot of the whole tree.
Tool from the stack
For component tests in React I would choose React Testing Library with Vitest.
That setup pushes the test toward user-visible behavior: text, roles, form fields, clicks, and messages.
For snapshots I would use Vitest snapshots, but sparingly.
A snapshot makes sense for stable output such as generated HTML, JSON, or a small component fragment.
I would not snapshot a whole page just to create a large file that gets accepted blindly.
When they are too large
A component test becomes too large when it has to fake half of the application.
several providers
several API mocks
complex routing
fake store
large environment setup
Then the test loses the simplicity of a unit test, but still does not give the confidence of E2E.
That is a sign to move the boundary: push some logic down to unit tests, and leave the critical path higher up.
The next level is integration tests, where we stop pretending one of the important dependencies exists.