i find that snapshot testing gets overused in javascript - and mistakes can creep in easily, and if the snapshot is big, and in a separate file, code review can miss it.
I much prefer property based testing over expectation based testing. You have to explicitly think about what properties hold true about the thing you're writing.
For example, fib(N+1) = fib(N) + fib(N), so this property can be tested for all N; primitive generators can easily generate the data, and good composition framework can easily generate complex data from primitive data.
Of course, you have to have a property you can specify easily. Otherwise, it'd be exactly the same as expectation based testing.
Every single time I've introduced property based testing, even as a simple example, I've discovered a bug in either the code or the spec.
I've found a bug in a Haskell program about fib generation - your test would work (if fixed for the subtractions) but incorrectly as there was an overflow in the addition. A basic property of "fib(n+1) > fib(n)" for n>1 finds this.
I like this type of testing as it asks you to more generally consider what guarantees your code is making about its operation.
Edit - your example is a good one and necessary, I just wanted to add a bit extra as I really like property based testing
Snapshot testing works well for component systems, especially with storybook. There is a service called Chromatic that lets you diff component changes visually using storybook output.
I much prefer property based testing over expectation based testing. You have to explicitly think about what properties hold true about the thing you're writing.
For example, fib(N+1) = fib(N) + fib(N), so this property can be tested for all N; primitive generators can easily generate the data, and good composition framework can easily generate complex data from primitive data.
Of course, you have to have a property you can specify easily. Otherwise, it'd be exactly the same as expectation based testing.