As part of the ndc-test refactoring work, I've ended up bikeshedding the approach to snapshot tests.
Since I'm refactoring out the console IO to the new Reporter trait, the only side effects lefts are the file IO for snapshot reads and writes. So it makes sense to think about factoring that out into a trait so that we can change the snapshotting behavior.
One example would be to test snapshots vs another running connector, e.g. to see if my postgres and mysql connectors for the same data differ on any queries I care about.
Another example would be a virtual filesystem approach for e.g. reviewing changes to snapshots before writing them back to disk.
As part of the
ndc-test
refactoring work, I've ended up bikeshedding the approach to snapshot tests.Since I'm refactoring out the console IO to the new
Reporter
trait, the only side effects lefts are the file IO for snapshot reads and writes. So it makes sense to think about factoring that out into a trait so that we can change the snapshotting behavior.One example would be to test snapshots vs another running connector, e.g. to see if my postgres and mysql connectors for the same data differ on any queries I care about.
Another example would be a virtual filesystem approach for e.g. reviewing changes to snapshots before writing them back to disk.
However, if we factor it out in the obvious way:
then there is a coupling between the caller and the implementation, since they both need to know the test directory.
Capability and schema calls are also a bit odd in that they don't have
request.json
files. Mutation requests have a different format entirely.This PR takes a different approach, and moves all snapshotting behavior into a new wrapper implementation of the
Connector
trait.