Snapshot testing does not work in practice
Snapshot testing is great on paper. In my experience, it does not work as great in practice. The goal of snapshot testing is to prove that your logic changes did not cause output side effects, typically to the UI. When I add a feature, my existing features shouldn’t break. When I optimize or refactor, my UI shouldn’t become inaccessible. That’s great!
In practice, UI changes so frequently that developers habitually update snapshots without considering if they need to be or even checking that they are valid. Snapshot testing, unlike other automated processes, is subject to human error.
My team dropped snapshot testing when we found that the snapshots had explicit errors in them. For example,
undefined was rendered instead of the expected text. Developers didn't read the snapshot. They made a UI change, such as a feature implementation or bug fix, ran the tests, saw that the snapshot changed as it should have, and updated the snapshot without reading the result. The fact that it changed to an errored view didn't come up as something to check, because “of course I didn’t mess up,” “a change was expected, so this is just the intended change,” and “who has time to read all that compiled, compressed, obfuscated, or human-unreadable code?”
Snapshot testing doesn’t work for the same reason a manual QA process doesn’t: human error. Don’t rely on best intentions. Automate testing. It’s fruitless to determine only that the UI is unchanged in a world where UI changes weekly. If your tests are not determining that the UI is accurate, drop them.