feat: snapshot testing (1/*) #995
Conversation
|
|
I like the idea of migrating to snapshots here. However it looks like from the code that you still need to add the manual 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: |
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
This is already possible in our infra: go test -v ./internal/... -run TestPrintToJSON/Fragment_LiteralThis command line will run only one test |
ematipico
force-pushed
the
chore/snapshot-testing
branch
2 times, most recently
from
39a14c9 to
9bfdccb
Compare
ematipico
force-pushed
the
chore/snapshot-testing
branch
from
9bfdccb to
7279642
Compare
Yes, I plan to update the contribution guide after merging this PR. The library freezes the snapshots by default, and you use an env var to update them. |
|
👍 Alright thanks! The state of the PR is fine by me in this case. |
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.