Introduce an upgrade/downgrade unit tester utility - #12892
Draft
redsun82 wants to merge 1 commit into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
testdirectory directly within the upgrade/downgrade script directory, andtake the form of a
<name>.trapfile containing the initial data of the DB and<name>.expectedcontaining 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>.actualfile is created, and--acceptcan be later used to accept the test result.
--learncan be used to directly write the result in the<name>.expectedfile.Two examples are included, involving a C++ upgrade script and a Swift downgrade one.