People use snapshot testing for convenience's sake, as opposed to line-by-line assertions, and it comes with a price. What you described in your post to me are the tradeoffs for the convenience. In my opinion, every single line of the snapshots are the test assertions. It basically specifies that the component should be exactly as it is defined in the snapshots. If you've been updating snapshots only because it failed, well, you shouldn't. You need to know why and all the failings have to be reviewed properly, much like you review your other non-snapshot test assertions.
As for changing one line causing many tests to fail, in my opinion, that is because the tests specify it that way (even in your snapshot testing's case). In my example, my idea of the context was that it could be because it was changing the interface (e.g. a sum function now takes in an array as the single argument instead of multiple numbers as multiple arguments), so all the tests for that code would fail anyway. My point is more on the mindset of complaining because fixing tests seems like an extra work, while in fact it is part of the work (updating specifications).
Patterns, best practices, what to do/not to do in testing might not be the scope of this article, but thanks for bringing that up anyway!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.