I don't see how you could TDD (as "write the test before changing the code") using snapshots. Do you have an example in mind?
Concerning complex objects, snapshots can be really handy indeed. Though, I would first ask myself:
Is my test actually testing the complete object? If I only care about some properties, I can use Jest's toMatchObject() for example.
Can I change the design so it's not that complex to write the expected object first? It really depends on what kind of object we're dealing with
Can I refactor my tests so it's not that difficult to see the expected changes? I might come up with a factory, for example.
But this often happens to me when I didn't write the tests first and I'm working with existing code, which is complex. I also realize that if it's complex for me to use in tests, it might be complex for other consumers of this code to reason about/use.
Although, I do use snapshots in such cases too:
either because it's code that didn't have tests in the first place, and I don't have time to write them by hand (which is more or less the scenario I described here)
either because we're dealing with UI tests (e.g. testing the rendered React view)
Either way, snapshots are "anti-regression" tests. Which is a valuable tool that I like to have. But when possible (and relevant), I try to think about what I want the code to do and I write an automated test first.
You can actually write the snapshot itself as if it was code. The main advantage over toMatchObject(...) is that you can also use property matches like Any<Date> in there.
Hi Alex!
I don't see how you could TDD (as "write the test before changing the code") using snapshots. Do you have an example in mind?
Concerning complex objects, snapshots can be really handy indeed. Though, I would first ask myself:
toMatchObject()
for example.But this often happens to me when I didn't write the tests first and I'm working with existing code, which is complex. I also realize that if it's complex for me to use in tests, it might be complex for other consumers of this code to reason about/use.
Although, I do use snapshots in such cases too:
Either way, snapshots are "anti-regression" tests. Which is a valuable tool that I like to have. But when possible (and relevant), I try to think about what I want the code to do and I write an automated test first.
You can actually write the snapshot itself as if it was code. The main advantage over
toMatchObject(...)
is that you can also use property matches likeAny<Date>
in there.Oh, I see! Indeed, that's an interesting way to do, thanks for sharing 😃
I wonder though: couldn't you use
expect.any(…)
to achieve the same, in your test code instead?Not sure. Let me test later, have a bunch of meetings ahead now.
It actually seems to work.