I just wanted to say that there was an article or video, I didn't read or watch, that suggested snapshot testing is a good thing. I think it's a complete waste of time, and occupies time that could be otherwise being spent crafting good unit tests that test the application the way the user actually uses it or tests that you've adhered to your state management solution correctly. I actually don't see much value in end-to-end (E2E) testing either--they're also brittle tests much like snapshots that have to be frequently updated in significant, non-trivial ways. I think that good unit testing along with a quality QA team really works best for me. Perhaps others do get some benefit from snapshot, integration, or E2E testing, but I just can't justify the time or expense associated with their upkeep and up-front costs. I'd be very curious to hear about someone who has Cypress for instance working well for them, or someone who can show me how to get the headaches out of snapshot testing. I'm not judging others, but in my two decades of experience with testing, unit tests and good QA engineers can't be replaced.
In terms of other testing - e2e and integration - I believe they have value and can be used to augment (not replace) unit testing, at the end of the day, most of your code should have a higher percentage of unit tests compared to other testing methodology.
Where I like about e2e and integration testing is they providing a sort of smoking test, where by you check whether the individual components came together nicely as expected and how they deal with real world data - data not matching our assumptions as developers.
And I am fully aware doing integration or e2e testing is really difficult, especially doing it well, you need to figure out how to solve the data problem, like spin up a version of your backend or application and seed it with realistic data and then run the tests against that environment.
But if you do it right and follow a workflow kind of approach (e.g. can a user login and do some activity), then it can be worth it, as it can provide further confidence to your developers they aren't breaking at least most of the critical flows of your application.
The snapshot testing explained in the video (may be a little confusing because if you are not aware of Jest snapshots it mind sound like something completely different) is mostly used as part of unit testing, at least that's where I have found it the most impactful. Instead of providing an output test to match an expect assertions, you can ask Jest to use the first output as the snapshot to compare future results against (of course you can update that if the output of the function changes and really only works well with pure functions) and I really like them as they are easy to work with. Especially when dealing with large data outputs for instance DOM tree or HTML outputs or Cloud formation templates. It saves a torn or work and for me personally I use it as one of the tools for writing unit tests.
I just wanted to say that there was an article or video, I didn't read or watch, that suggested snapshot testing is a good thing. I think it's a complete waste of time, and occupies time that could be otherwise being spent crafting good unit tests that test the application the way the user actually uses it or tests that you've adhered to your state management solution correctly. I actually don't see much value in end-to-end (E2E) testing either--they're also brittle tests much like snapshots that have to be frequently updated in significant, non-trivial ways. I think that good unit testing along with a quality QA team really works best for me. Perhaps others do get some benefit from snapshot, integration, or E2E testing, but I just can't justify the time or expense associated with their upkeep and up-front costs. I'd be very curious to hear about someone who has Cypress for instance working well for them, or someone who can show me how to get the headaches out of snapshot testing. I'm not judging others, but in my two decades of experience with testing, unit tests and good QA engineers can't be replaced.
In terms of other testing - e2e and integration - I believe they have value and can be used to augment (not replace) unit testing, at the end of the day, most of your code should have a higher percentage of unit tests compared to other testing methodology.
Where I like about e2e and integration testing is they providing a sort of smoking test, where by you check whether the individual components came together nicely as expected and how they deal with real world data - data not matching our assumptions as developers.
And I am fully aware doing integration or e2e testing is really difficult, especially doing it well, you need to figure out how to solve the data problem, like spin up a version of your backend or application and seed it with realistic data and then run the tests against that environment.
But if you do it right and follow a workflow kind of approach (e.g. can a user login and do some activity), then it can be worth it, as it can provide further confidence to your developers they aren't breaking at least most of the critical flows of your application.
The snapshot testing explained in the video (may be a little confusing because if you are not aware of Jest snapshots it mind sound like something completely different) is mostly used as part of unit testing, at least that's where I have found it the most impactful. Instead of providing an output test to match an expect assertions, you can ask Jest to use the first output as the snapshot to compare future results against (of course you can update that if the output of the function changes and really only works well with pure functions) and I really like them as they are easy to work with. Especially when dealing with large data outputs for instance DOM tree or HTML outputs or Cloud formation templates. It saves a torn or work and for me personally I use it as one of the tools for writing unit tests.