Weird stuff and how to test it
blog.lawrencejones.dev
blog.lawrencejones.dev
But if you use the snapshots as a means of understanding the templating and checking what it alters, people are much happier to examine the diff.
Agreed that VRT is more powerful: Jest was the first place I found this technique, though I've seen it for other things like SQL approvals before.
A few off the top of my head. Many e2e testing tools can capture and compare screenshots but I think to be maximally effective (and minimally frustrating) you want a tool to manage approving, reviewing, etc.
Now, I can’t predict whether the snapshots will remain valuable over the long term. I expect they won’t, but mainly because I’d like to see this library eventually fade away and its responsibilities move into its primary downstream target. But that may take years, it took nearly two years to get to this refactor which will help enable that. I’m betting the snapshots will be equally valuable whenever that goal becomes possible. In the meantime, they’re my best assurance that I can honestly tell people I believe the current work I’m doing is safe and correct.
I don’t think they’re right for every project or every testing scenario in a given project, but knowing when they are a great fit is important too.
This is a short post about how to apply tests to problems outside the space of normal code. It covers two strategies – snapshot testing and verification of real production systems – using examples taken from my career, where investing in a way to test was really worthwhile.
The broader point is that processes or strategies you find in one part of software engineering can often be used to great effect in others, if you're willing to try.
I've got weirder examples, such as hacking TypeScript/BigQuery/dbt/Metabase to inject user-defined-functions into a production system, but these felt the most generally useful.