Fix and Retest
Overview
When the Test Harness tests run, it will look for change and snapshot tests and expectations in your src/test/resources/liquibase/harness
directory.
Finding Files
The test harness uses an algorithm of finding the "most correct" version of files for your database. These files are used for both defining what to test and also what to expect.
The base search directory is src/test/resources/liquibase/harness/*
with different subdirectories for each type of test. For example, the "change" tests use a ${base directory}
of src/test/resources/liquibase/harness/change
.
When searching for a file such as file.ext
, Test Harness checks for the following pattern:
${base directory}/${db name}/${major version}/{$minor version}/file.ext
${base directory}/${db name}/${major version}/file.ext
${base directory}/${db name}/file.ext
${base directory}/file.ext
where it uses the contents of file it finds.
This means that when defining "expectedSql" or changelogs or expectedSnapshots or any other file test harness expects, you can override the default expectations by creating new files higher up in the pattern.
Tip
Keep your files as generic as possible. If the expectedSql file works for all versions of your database, create the file in ${base directory}/${db name}/file.ext`.
Only use major and minor versions when it actually depends on the specific versions.
Golden Master Files
Many of the tests use "expected" files and will either auto-create them if they do not exist or fail until the file is created.
These files let you manually inspect the SQL being run by a particular change setup to ensure it is doing what you expect now, and will be checked into Git so that it is easy to detect any changes to this known good behavior down the road.
Fixing Logic
For tests that are failing because how Liquibase interacts with the database needs to be customized for your database, you will create one of two types of classes:
- New SqlGenerator implementations for Change -> SQL mappings that are wrong
- New SnapshotGenerator implementations for snapshot logic that is wrong
The general pattern for both is to create a new class that returns a higher priority if and only if Liquibase is using the Database
class you defined in milestone 1.
Next Step
Once all the Test Harness tests are passing, you will be able to use change types in XML/YAML/JSON changelogs as well as any snapshot-based functionality. For example, all of this should now work:
liquibase update
with<createTable...
in the changelogliquibase update
with<tableExists...
preconditions in the changelogliquibase snapshot
liquibase diff
liquibase diff-changelog
liquibase generate-changelog
Created: January 9, 2023