[drinchev]

The snapshots part is something that I completely disagree.

> Here, we change the engine type from turbofan to propfan. Just to test how it works. Since the new engine no longer matches our snapshot, the test fails. We’ve got a report, and our engineers are on their way to investigate the problem.

I would be really happy if I know that the onboard computer has tests that checks if the engine being used is compatible before it takes off.

IMO, tests in general should be as close as possible to the real use-case ( kudos for the screenshot testing ) and as far as possible from the implementation. What happens with snapshots is that you are bound to the implementation. Maybe I have a logic somewhere in my code that does s/propfan/turbofan/. Would a user be interested in that or the functionality itself?

We ditched all JEST's snapshots statements in our code-base, because of code-coverage abuse and false sense of "being safe" just a couple of months ago. It was a good decision that helped us be closer to "what the user sees" rather than "what the markup should be"

[bickeringyokel]

Am I misunderstanding, or are snapshots basically just schema validation?

[simoncarter]

It's more akin to file diffing. Developers are notified of any differences in snapshots. The developer can they either accept the new snapshot, or investigate and fix.

[steve_adams_86]

Sort of - It ensures that your logic still generates the same output as before, so perhaps a step after the schema and a little closer to the user. I think people take it to mean the output will still look the same for the end user, though. That's rarely the case since markup is typically styled by CSS. CSS changes will largely be missed in the snapshots unless a class name is added, removed, or updated in the markup.