Snapshots are still an assertion, but can become broad ones. Favor specific assertions where workable.
Jest Snapshots can be a valuable utility for monitoring code changes for UI components. They can also become a scourge if they become too large. The line between the two isn't always clear. Snapshots don't offer a clear mechanism to determining how large they are. This makes it easy to create large snapshots that are hard to diff.
The likelihood of a thorough review on a snapshot diff decreases in relation to the size of the snapshot. I have both observed and committed broken snapshot updates into repositories as part of a branch. The danger lies in making intentional changes to a particular feature and updating the snapshot without checking for other breakages. If the snapshot diff is large, it will likely not receive as thorough a review. Snapshots are only as good as the level of review they receive. If you update and commit a broken snapshot it is more difficult to use that as a method for identifying issues.
One tool that can help combat growing snapshots is the Jest ESLint plugin for large snapshots. This rule can set a maximum length for a snapshot before the rule will warn or error out. This brings awareness to the size of a snapshot. If a snapshot becomes too large, it is harder to check for breaking changes. Writing more pointed assertions may better serve the testing needs. The rule defaults to 50 lines. Depending on the test use cases this may be unrealistic. For React development, something closer to 200-300 lines is more realistic.
There are other means of addressing poor snapshot usage in tests. These additional measures, combined with the ESLint rule, can help mitigate some risks of blind snapshot updates.
iwhen in watch mode. Jest will display one snapshot at a time. You can update the current snapshot by pressing
u, or press
sto skip it. This enables more granular control over updating snapshots.