When snapshot tests fail after a security bump, do not run the update command until you have read the diff. Update the snapshot only if the change is explained by the release notes, harmless to users, and small. If you cannot explain a line, treat it as a behavior change and investigate before merging.
Why a fix pull request trips snapshots
A snapshot test stores the rendered output of a component or function and compares it on every run. A security fix to a library can change that output in small ways: an attribute is now escaped, whitespace is trimmed, an element gets a new default attribute, or a URL is normalized.
Some of those changes are the fix itself. Escaping that used to be missing is the vulnerability, so a snapshot that captured the old output was recording the bug. Others are accidental side effects the maintainers did not flag. You cannot tell which is which from the red test alone.
The Jest documentation says snapshot files should be committed and reviewed as part of your code review process. It also warns against the habit of regenerating snapshots when test suites fail instead of examining the root causes of the failure. A fix pull request is exactly where that habit does damage, because the pull request looks routine.
A four step triage
- Read the diff line by line. Do not scan it. Note every changed attribute, tag, string and ordering difference.
- Match each line to a reason. Look in the release notes and changelog for the fixed version. If a line has no matching entry, mark it unexplained.
- Ask who sees it. A changed class name in an internal admin screen is low risk. A changed escaping rule in a rendered user comment is worth a manual check in a browser.
- Decide per snapshot, not per run. Update the explained ones in the same pull request, and say so in the description. Hold the pull request for the unexplained ones.
A quick decision table
| What the diff shows | Likely cause | Action |
|---|---|---|
| Extra escaping of quotes or angle brackets | The fix itself | Update, then test the page manually |
| New attribute added by the library | Hardening default | Update, note it in the pull request |
| Reordered keys or attributes | Harmless change in output order | Update if no test depends on order |
| Missing element or text | Behavior change | Investigate before merging |
| Large rewrites across many files | Output format changed | Pin the old version, read the full diff |
When snapshots are the wrong tool
Large snapshots are hard to review, and people stop reading them. The Jest docs point to keeping snapshots short and focused so they are easy to review in pull requests. If a security fix touches a component with a 400 line snapshot, consider adding one narrow assertion that matters, such as "user supplied text is escaped", and keep the big snapshot as a secondary signal.
Also check that snapshots are not being written automatically on your CI system. The same documentation notes that new snapshots pass automatically, so they should not pass on a CI run. Running tests in CI mode makes a missing snapshot fail instead of quietly passing.
If your team uses a tool that opens fix pull requests for you, decide in advance who may update snapshots. A sensible rule is that the person approving the pull request reads the snapshot diff, not just the pass or fail result. Safeguard can open fix pull requests through autonomous remediation, which is off by default with every category on Manual, so a person reviews each change before it merges. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Is it ever fine to bulk update every snapshot?
Rarely. It is acceptable when a release note explains a systematic output change across the board and you have spot checked several files. Even then, keep the snapshot update in the same commit as the bump so a reviewer can see both.
What if the snapshot diff is hundreds of lines?
Split the work. Pin the old version, write a narrow test for the behavior you care about, then upgrade and review only the lines that fail that test and the ones you cannot explain.
Sources
Last reviewed: 19 October 2026.
