Hello,
I was wondering if anybody has tried Liquibase to do what we would generally do with DBUnit: http://www.dbunit.org
That is, to set up the database, populating the seeds, execute changes - all in imperative mode during development instead of declarative definitions in the changelog.
Regards,
Shantanu
I’ve thought about it at it a little bit, the context attribute can be used to segregate out “test” insert statements, even into different datasets. What I like about having a liquibase-based test dataset management tool is that the test data will migrate along with the production data, so you don’t have to continually update your test data configuration as your database structure changes.
I haven’t worked on much beyond that, but I am sure there is more that could be done. Does anyone have suggestions on new liquibase functionality that could help with managing test data?
Nathan
I like the idea of letting liquibase migrate test data. Additionally, I would like to be able to mess with that test data in my test case and then rollback and reapply the test data to restore to original state for the next test. This would avoid having to completely wipe out database and start over with ‘liquibase create table’.
The problem is that liquibase does not support rollback for all types of refactorings it has. So I can’t rollback a few changesets up to the time my test data was created and reapply those again. So far I don’t see any other option except than to reset the whole DB. Obviously, I’m talking about in-memory DBs so some kind of statement like ‘shutdown’ does it. But starting up again and applying all liquibase changesets is a little slow.
I think rolling back insert statements could be possible if certain restrictions apply:
- no on/after insert triggers
- primary key Ids are specified in xml, so you can just delete it
- single test data changeset, so all data can be removed in one transaction without violation of foreign keys
- liquibase has to be able to either disable some foreign keys or delete rows from tables in specific order to avoid FK violation again.
- No other DML allowed to keep it simple
- maybe a lot of other stuff that I’m just missing… 
I’d like to hear about how other people handle test data.
