Introduce an upgrade/downgrade unit tester utility #12892
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is meant specifically for unit testing upgrade/downgrade scripts, that is to throw small DBs at them and checking the effect, without involving the tracer or extractor, using raw trap files instead.
Tests must be contained within a
test
directory directly within the upgrade/downgrade script directory, andtake the form of a
<name>.trap
file containing the initial data of the DB and<name>.expected
containing aform of difference between the database before and after the upgrade/downgrade is applied, similar to the format
of
codeql database diff
. It is required and checked that the initial data is consistent withold.dbscheme
, andit is then checked that final data is consistent with the new dbscheme.
Behavior is similar to
codeql test run
: if the test fails, a<name>.actual
file is created, and--accept
can be later used to accept the test result.
--learn
can be used to directly write the result in the<name>.expected
file.Two examples are included, involving a C++ upgrade script and a Swift downgrade one.