Even if I agree with what you said on how snapshot testing isn't great for testing individual components, I find it very useful to test side-effects. When you update a component, you know exactly how much components are affected by that change and you can easily check if that's wanted or not.
It's also great when you update dependencies, by just running the snapshot tests you can check if a minor update didn't break anything and what a major update broke.
I don't think you should do one or the other, they're very different and having both can help a lot : Assertions to test an individual component's behavior and Snapshots for side-effects.
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.
Interesting. You realize you are essentially duplicating your tests when you snapshot the component AND the components who use it. If they have already been thoroughly tested, shouldn't you be able to trust the components? Shouldn't all the use cases be described in the component test suit? If you're using a third-party library and you update it and it meets all the requirements previously met at your tests, doesn't that mean it doesn't break anything? Don't you think having actual assertions for all the requirements of your components would suffice (aside from giving you more precise error messages and being more resilient to changes)?
Totally agree.
You usually write tests to be sure that your code changes are not breaking stuff and only changes the components you want.
Imagine you're working on a project along with another 40 small teams. You use some shared components, and you make the change in a shared component, some other teams are not expecting neither functional nor visual changes to component.
As to use your example. You have a card with image and text, you're using this component for listing of blog posts and you expect it to have a link so that clicking on it will lead to a blog post. Other team is using the same component to render the header of blog post on mobile view, with the same image and title, and they expect no link there. Here's where snapshot testing will help you out.
Also using your example, I'd say it makes more sense to have a new component that would be clickableCard or cardWithLink so that you don't change nor add functionality to a visual component.
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.
Even if I agree with what you said on how snapshot testing isn't great for testing individual components, I find it very useful to test side-effects. When you update a component, you know exactly how much components are affected by that change and you can easily check if that's wanted or not.
It's also great when you update dependencies, by just running the snapshot tests you can check if a minor update didn't break anything and what a major update broke.
I don't think you should do one or the other, they're very different and having both can help a lot : Assertions to test an individual component's behavior and Snapshots for side-effects.
Interesting. You realize you are essentially duplicating your tests when you snapshot the component AND the components who use it. If they have already been thoroughly tested, shouldn't you be able to trust the components? Shouldn't all the use cases be described in the component test suit? If you're using a third-party library and you update it and it meets all the requirements previously met at your tests, doesn't that mean it doesn't break anything? Don't you think having actual assertions for all the requirements of your components would suffice (aside from giving you more precise error messages and being more resilient to changes)?
Totally agree.
You usually write tests to be sure that your code changes are not breaking stuff and only changes the components you want.
Imagine you're working on a project along with another 40 small teams. You use some shared components, and you make the change in a shared component, some other teams are not expecting neither functional nor visual changes to component.
As to use your example. You have a card with image and text, you're using this component for listing of blog posts and you expect it to have a link so that clicking on it will lead to a blog post. Other team is using the same component to render the header of blog post on mobile view, with the same image and title, and they expect no link there. Here's where snapshot testing will help you out.
Also using your example, I'd say it makes more sense to have a new component that would be
clickableCardorcardWithLinkso that you don't change nor add functionality to a visual component.