Liquibase code contains both unit tests and integration tests. This document explains the basics for creating Integration tests that will be used by the automated build process to validate Liquibase and reduce regressions.
Why do we have Integration Tests?
The goal of integration tests are to:
- Verify that various Liquibase components work in concert with each other correctly (including end-to-end scenarios)
- Verify that Liquibase interacts correctly with databases and other external systems
What can be tested?
The overall flow within Liquibase is shown on the left. Each integration test should focus on the relevant component in the flow that has been implemented or changed.
For example, to test that a particular configuration of a CreateTableChange object works, the test would start with the Change object and test the rest of the flow to ensure it correctly creates the table in the database. It shouldn’t start with a changelog file, because that particular test doesn’t care how an xml/json/yaml file is converted into that Change object, it just cares that the Change object itself works.
If you are wanting to test that a particular XML tag is being handled correctly, you can create the file in your integration test and run it though the changelog parser and assert that the created CreateTableChange object matches what you expect. Stopping the flow at that point vs. letting it run all the way to the database is generally better because it is the interaction with the database that is slow and not always available, so the more you can focus your test on the parts of the overall flow that you are interested in, the better.
What is required to make the integration tests work?
The integration test framework consists of the following components:
- Liquibase Core
- The Integration Test
- If testing a database, you’ll need to configure a database
