A green test suite is a blank canvas, and a blank canvas is a paralyzing place to start.
A failing test is a pointer to the next step. When I end the day with a failing test, I know exactly where to begin when I get back. The perfect kickstart to get into flow.
Christopher Pitt wrote a pretty comprehensive article on one of our latest packages, which is one of my favorite packages I've written at Spatie to date, phpunit-snapshot-assertions.
Ah-ha moments are beautiful and rare in programming. Every so often, we’re fortunate enough to discover some trick or facet of a system that forever changes how we think of it. For me, that’s what snapshot testing is.
Read the full article on SitePoint, or check out
phpunit-snapshot-assertions on GitHub.
The gist of snapshot testing is asserting that a set of data hasn't changed compared to a previous version, which is a snapshot of the data, to prevent regressions. The difference between a classic and an is that you don't write the expectation yourself when snapshot testing.
When a snapshot assertion happens for the first time, it creates a snapshot file with the actual output, and marks the test as incomplete. Every subsequent run will compare the output with the existing snapshot file to check for regressions.
Snapshot testing is most useful larger datasets that can change over time, like serializing an object for an XML export or a JSON API endpoint.