It's easy to do it with one component, but what will it happen you have 50 different components using the changed component and all the snapshots tests break?
The most common complaint I've heard about snapshot tests is exactly this; but if this happens then you're doing something wrong. In my experience snapshot tests are absolutely fine if you shallow render the tested component and limit the scope of your snapshot. So, if you are testing a large component, write tests that target specific elements and snapshot those; rather than taking a snapshot of the whole component. Then when a test fails the diff is kept small enough to parse quickly and establish if the change is expected.
Of course there are times when you shouldn't use them; but for dumb components they can definitely be a massive time-saver and, as Michael McGahan says, they're the most effective way to test rendered markup if that happens to be critical to your application. I feel their only drawback is a lack of understanding of how to apply them effectively :/
Self-taught developer and OSS enthusiast. I'm specialized in Front End development but I don't miss a chance to do JS anywhere, whether it's a browser, a mobile device, a server or a robot.
Fair enough, if you limit the scope of your snapshots you can indeed minimize the problem and save time. I still feel like saving time on your tests means losing time later that you'd not have lost if you had better error messages.
Would you fill a single test with all the assertions required to properly test your component? Obviously not... No-one should be doing that with snapshot tests either.
To be fair one other problem with snapshot tests is a certain amount of hype they've attracted that means their value has been oversold. You still have to think carefully about how you structure your tests in order to be most effective. So no, a single snapshot test cannot magically replace multiple, properly targeted tests.
But I'd still contest the time-saving aspect. When I see the diff on a failed test it's fairly trivial to establish whether it's styling/layout related and quickly update where appropriate. And when output is not as expected do I need an error message that says the output doesn't match the expected value? No: that's also immediately obvious from the diff.
I've seen some terribly written assertion tests that unnecessarily increased the burden of maintenance; that could easily be replaced with equally (if not more) effective snapshot tests; but that doesn't mean I won't ever write assertion tests...
Don't blame the tool: just learn how and when to use it properly ;)
Self-taught developer and OSS enthusiast. I'm specialized in Front End development but I don't miss a chance to do JS anywhere, whether it's a browser, a mobile device, a server or a robot.
Alright, you do have a point. As usual, it's a matter of trade-offs. Thank you for taking the time to discuss it. I personally have been moving away from snapshots and shallow rendering and definitely felt the weight that they add when refactoring components on an old enough codebase. I don't think testing implementation on the front (e.g. markup) is healthy for a long term project. I've been favoring testing of behavior with @testing-library/react instead. They are much more resilient. That said, they don't cover the visual aspect, but we could argue that a visual testing tool is more suited for this job.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The most common complaint I've heard about snapshot tests is exactly this; but if this happens then you're doing something wrong. In my experience snapshot tests are absolutely fine if you shallow render the tested component and limit the scope of your snapshot. So, if you are testing a large component, write tests that target specific elements and snapshot those; rather than taking a snapshot of the whole component. Then when a test fails the diff is kept small enough to parse quickly and establish if the change is expected.
Of course there are times when you shouldn't use them; but for dumb components they can definitely be a massive time-saver and, as Michael McGahan says, they're the most effective way to test rendered markup if that happens to be critical to your application. I feel their only drawback is a lack of understanding of how to apply them effectively :/
Fair enough, if you limit the scope of your snapshots you can indeed minimize the problem and save time. I still feel like saving time on your tests means losing time later that you'd not have lost if you had better error messages.
Would you fill a single test with all the assertions required to properly test your component? Obviously not... No-one should be doing that with snapshot tests either.
To be fair one other problem with snapshot tests is a certain amount of hype they've attracted that means their value has been oversold. You still have to think carefully about how you structure your tests in order to be most effective. So no, a single snapshot test cannot magically replace multiple, properly targeted tests.
But I'd still contest the time-saving aspect. When I see the diff on a failed test it's fairly trivial to establish whether it's styling/layout related and quickly update where appropriate. And when output is not as expected do I need an error message that says the output doesn't match the expected value? No: that's also immediately obvious from the diff.
I've seen some terribly written assertion tests that unnecessarily increased the burden of maintenance; that could easily be replaced with equally (if not more) effective snapshot tests; but that doesn't mean I won't ever write assertion tests...
Don't blame the tool: just learn how and when to use it properly ;)
Alright, you do have a point. As usual, it's a matter of trade-offs. Thank you for taking the time to discuss it. I personally have been moving away from snapshots and shallow rendering and definitely felt the weight that they add when refactoring components on an old enough codebase. I don't think testing implementation on the front (e.g. markup) is healthy for a long term project. I've been favoring testing of behavior with
@testing-library/reactinstead. They are much more resilient. That said, they don't cover the visual aspect, but we could argue that a visual testing tool is more suited for this job.