feat: snapshot testing (1/*)

[ematipico]

Changes

I realised some time ago that testing inside the compiler can be a bit difficult due to the fact that sometimes we don't have "the whole picture": when we want to assert something, we just check that a portion of the text contains something. However, this isn't always sufficient because we can't see and understand the emitted artefact of the compiler.

This PR proposes to attempt to add snapshot testing inside our compiler infra.

In this PR, as a start, I implemented snapshot testing on top of our internal testing suite. I modified the snapshot testing library to emit a new snapshot file for each testing case to avoid tarnishing the same snapshot every time we add a new one.

What do you think?

Testing

The tests should pass

Docs

Later, if and once snapshot testing is implemented throughout the codebase.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0cd51d9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[matthewp]

I like the idea of migrating to snapshots here. However it looks like from the code that you still need to add the manual want{}, so I think we should get rid of that if we're going to go with snapshots instead.

The bigger issue with testing, imo, is that we have this one giant test for every scenario in the print. This makes it hard to run a single test. There's a convention in go to test a single test: go test -run "Name of Test", but you can't do that with our tests because they are all inside of a single func TestPrinter. So if we're going to improve our testing, I'd like to see the metaprogramming stuff go away and just have a list of test functions so it's easier to run them in isolation.

[ematipico]

However it looks like from the code that you still need to add the manual want{}, so I think we should get rid of that if we're going to go with snapshots instead.

That's done on purpose, I find it useful to use both approaches: check for a string and still printing the snapshot, mainly because when creating a new test, sometimes there isn't a clear understanding of when a snapshot is valid, so the want{} should be available (maybe optional) when needed.

The bigger issue with testing, imo, is that we have this one giant test for every scenario in the print. This makes it hard to run a single test.

This is already possible in our infra:

go test -v ./internal/... -run TestPrintToJSON/Fragment_Literal

This command line will run only one test