We were able to write some unit tests for Button component in previous lesson. What if I tell you that we're able to cover all parts with almost 2 lines of testing code? Let's check how snapshot tests works and what you can achieve and what you can lose with them.
Creating snapshot test
Sometimes if you're writting presentational component you'll produce big DOM tree. How to test such components? You can try to compare generated properties with expected ones.
What if you need to verify other properties like style object. It may be really complex object, you can check how complex in following article. To achieve it fast someone smart invented snapshot testing.
Imagine you are playing a computer game and you saved your progress. Bravo! It's a snapshot test. Now every time you lose you can start from a safe moment.
So how it works in jest and React? You need to replace previous test with following one:
When you run test command the __snapshots__ directory will be generated near your test file. Inside you can find following snapshot file:
Generated folder and file
That's your snapshot
Check the following gif to understand how you can use snapshots in daily basis:
Truth about snapshot testing
You may be thinking now - great I will use this new approach everywhere. This will be a big mistake 🚀. These tests must be used carefully. They're easy to write but hard to maintain. They will fail always when something change so you need to manually check these changes. They're are useful to prevent "any" regression but when overused they cause headaches.
Also, they're much more fragile than previous test with className check. If you change button to span - they will fail. If you add additional property to component - they will fail. You need to go through changes and check they are valid or not.
To avoid problems with maintenance create snapshot tests only if:
You're sure that something is working correctly
You don't have time for better tests
You're testing complex HTML properties generation
Component is pure presentational
A very important point is namely that if our snapshot is saved when the component is not working properly, such tests begin to be a problem. You need to be careful and focused when using them.
To understand what damage they can cause - it is enough to change the snapshot of the component at the moment when it works incorrectly, and then push these changes to the repository. Good luck with fixing and reviewing hundreds and thousands of such tests.
I personally use them very rarely. I prefer to have more complex test code, and even implementation-dependent, than to rely on something that checks any change.
How to work with snapshot tests?
Check out the list below:
Create a component and make sure manually that it works correctly
Create snapshot test to prevent regression
If you will have some time - jump to tests and write concrete ones
You can remove or leave snapshot test as it is (maybe it still covers uncovered paths) - u2y
Look at following test file to understand how I'm using snapshots:
We learned today snapshot tests and how useful/harmful they can be at one time. Tests should be reliable, stable and should answer the question - whether something works or not, so snapshots should be used with caution.
If you enjoyed it, be sure to visit us on Linkedin where we regularly upload content from programming.
- 1. Basics
Grouping the tests
The usage of describe and it
The best practices for naming tests
Types of tests
- 2. Mastering unit testing
Project and tests setup
Unit tests review
React component testing
Snapshot testing in React
Understanding stubs in testing
Understanding mocks in testing
Creating testing fixtures
Using spies in React and Typescript
Mocking environment variables
- 3. Mastering integration testing