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.
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.