Explore switching release and package tests to be snapshot tests

[romaricpascal]

What

See if we can change some or all of the tests checking the content of our package and release to use snapshot testing, rather than hardcoded strings in each test.

Before actually making changes, we'd want to have a little assessment of the impact on moving to testing beyond us not having to maintain the hardcoded strings. Especially what the process would be for fixing failing tests, which we should document.

Why

After building either govuk-frontend's package files (running npm run build:package) or dist (running npm run build:release`), our tooling runs some tests to check the content of what's been built.

These tests do a lot of string matching that need to manually maintained. Moving to snapshot tests should avoid us having to maintaining the strings being compared manually, while still giving us a warning when things change.

While there should be a gain in maintainability by not having to keep track of the compared strings manually, we need to make sure fixing the tests won't be to much of a burden after we switch to snapshot testing. Both tests run on CI so it won't be a release-day surprise, but we'll need to update the snaphshot every time we add a new component or a new function to our public API.

Who needs to work on this

Developers

Who needs to review this

Developers

Done when

• We've reviewed the impacts of snapshot testing
• We've updated the tests that could use snapshot testing
• We've documented how to update the snapshots when tests fail.