Testing Liquibase extensions

Liquibase Development
1

Hi,

I am at a stage where the Liquibase-Clojure library has ‘update’ and ‘rollback’ functionality working and has most Change types implemented - I have been working on it for some time now. Now I am onto testing this library until it reaches v0.1 stage – I will publish this as an Open Source project around that time.

Can somebody please share experience with testing other Liquibase extensions and any advice that I can use? I am trying to build some basic test harness that might be useful – your input will be very appreciated.

Regards,
Shantanu

2

(note: i’m not sure what you are doing with your extension, so the below is a guess based on thinking/remembering you were implementing a clojure-based changeset DSL.)

If you look at the main liquibase source, under the liquibase-integration-tests you will see how we test the changeSets in the core library.  We basically have changelogs that contain the changesets that we want to test.  I’m hoping to wrap it all up nicer for extensions to use, but have not gotten to it yet.  Part of the issue is thinking through what sort of testing extensions of differet types (changelog parsers, databases, etc) would want to do.

For your extension, I would think you would want to do something similar where you create various changelog/changesets and execute them.  I’ve found tests against the H2 database type run the fastest, and if you are primarily doing changeset parsing, you shouldn’t have to worry about database compatability.

Another option would be to test just the changelog parsing more from a unit testing layer.  You could write tests that take a text string containing your closure dsl and run it through the ChangeLogParserFactory.getInstance().getParser(ext, accessor).parse() method and assert on the returned DatabaseChangeLog object.

Nathan

3

Thanks Nathan. Now that I have published the sources, you can see it uses a Clojure DSL to build the changes, changesets and changelogs. It doesn’t involve parsing and it rather invokes the Liquibase API directly. I am wondering about three possible approaches for testing this:

  1. Since Liquibase is already tested well enough, maybe I can just ascertain that whether Clj-Liquibase can correctly construct the Change, ChangeSet and ChangeLog objects. While doing so, I would need to test for consistency with respect to all ‘required’ arguments and ‘optional’ arguments. This is the minimalistic approach.

  2. Full integration-test like how Liquibase-core does it. This implicitly includes #1 (above).

  3. Apply #1 for Change objects and #2 for ChangeSet and ChangeLog objects.

In any case, I certainly need to test whether the Clojure arguments are correctly converted to valid Liquibase arguments (for example, a keyword :foo should be converted to string “foo” across the board - schema/table/column/argument names can be expressed as keywords) and run some additional integration tests for the end-to-end cycle. Any comments on this? Do other extensions follow approach #2?

Regards,
Shantanu

4

As of now I am taking route #3 for testing - so far all Change implementations are unit tested successfully except the AddDefaultValueChange (I need to figure out the serialization format) and also ChangeSet and DatabaseChangeLog implementations. Among the actions only one version of ‘Update’ action is unit tested successfully; I am yet to write the rest.

You can check the progress here: https://bitbucket.org/kumarshantanu/clj-liquibase/src

Regards,
Shantanu

5

I think that makes sense for a testing approach.  I’ll take a look at your test sources and see if I have any suggestions (if I can follow the clojure :slight_smile: )

Nathan