It looks like you fell into the Unit Test Trap. The solution is not two do snapshot massively, but it is to start thinking in the business value of your code.
Snapshotting might seem useful and magic, but it has two problems:
- You have to review each pair of data to check if they are correct.
- Sooner or later, the output does not match, but it might be valid.
You have to review the output the first time. It might seem more straightforward, but other times it is harder, mainly when we have to consider the details. Think in the future, when a new input appears, do you know exactly how to validate the output? My experience says that people overlook the details.
The second problem is more prominent. The idea behind testing is to represent the business value so we can refactor the code safely. Safely does not means that the program does the same, but the application satisfies all previously defined business logic. And that is a big problem for snapshotting. Eventually, a new requirement demands to change an existing output, and that breaks your tests, and usually more than one. At that moment, you have to look at the result, analyze it, and determine if it is safe to change. The question is, if you have no record of the business rules, how can you be secure that the change is correct?
The main reason for testing is keeping track of the business rules that are alive. They change with time, evolve, got destroyed, replaced, but the ones living in tests are those that are still relevant today. They are priceless and more valuable than the production code.
Some years ago, I was a detractor of testing for many of the same reasons that you have exposed. Not so far ago, I realized that I had fallen in the Unit Test Trap, but I left the trap, and now I love testing. I recommend you to read my post about:
