Learn the vocabulary of comparing a component's rendered output against a previously saved reference file.
0 / 5 completed
1 / 5
At standup, a dev mentions capturing a component's rendered output once, saving it as a reference file, then automatically comparing future test runs against that saved reference to flag any unexpected change. What is this technique called?
Snapshot testing is exactly this: snapshot testing captures a component's rendered output once, saves it as a reference file, and automatically compares future test runs against that saved reference, flagging any difference as a potential unintended change for a developer to confirm or reject. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This capture-once-then-compare approach is exactly why snapshot testing can catch unintended UI changes without a developer having to write assertions for every visual detail by hand.
2 / 5
During a design review, the team adds snapshot testing for a component with many small visual details, specifically because comparing future renders against one saved reference file avoids writing a separate hand-written assertion for every individual visual detail. Which capability does this provide?
Snapshot testing here provides Broad regression coverage without writing per-detail assertions, since the saved reference captures the entire rendered output at once, and any unintended change to any detail shows up as a diff without needing a hand-written assertion for that specific detail. Writing a separate hand-written assertion for every individual visual detail would be extremely tedious and would still miss details no one thought to assert on. This capture-the-whole-output behavior is exactly why snapshot testing is favored for catching unintended changes across components with many small visual details.
3 / 5
In a code review, a dev notices a component with many small visual details is tested only with hand-written assertions checking a few specific properties, with no snapshot test comparing the full rendered output against a saved reference. What does this represent?
This is a missed snapshot-testing opportunity, since comparing the full rendered output against a saved reference would catch unintended changes to any detail, instead of relying on hand-written assertions that only check the few properties someone thought to assert on. A cache eviction policy is an unrelated concept about discarded cache entries. This assertions-only pattern is exactly the kind of coverage gap a reviewer flags once a component has many small visual details worth protecting.
4 / 5
An incident report shows an unintended visual regression shipped to production in a component detail no hand-written assertion happened to check, because the component relied only on hand-written assertions with no snapshot test comparing the full rendered output. What practice would prevent this?
Adding a snapshot test compares the full rendered output against a saved reference, catching regressions in details no hand-written assertion checks. Continuing to rely only on hand-written assertions checking a few specific properties regardless of how many other visual details the component actually has is exactly what caused the issue described in this incident. This snapshot-testing practice is the standard fix once a component is confirmed to have visual details worth protecting beyond what assertions check.
5 / 5
During a PR review, a teammate asks why the team adds a snapshot test on top of already-thorough hand-written assertions for a component. What is the reasoning?
Hand-written assertions only catch changes to the specific properties someone thought to check, while a snapshot test compares the entire rendered output against a saved reference and flags any unintended change, making the two complementary rather than redundant. This is exactly why thorough test suites combine both, rather than treating either one as a full substitute for the other.