liquiunit 1.0.0-SNAPSHOT

Thanks for the heads up. Liquibase for managing test data has always made a lot of sense, it’s good to have some structure and convenience around that.


Nathan

Actually, with respect, dbUnit deals with test data much better.  But using Liquibase to set up the “default data”—the data that defines your “empty” production system—in your test system too, in the same way that it sets up your production database, makes a ton of sense.


The chief problem with managing test data with Liquibase is that there’s not any support built in for doing something with the test data.  In unit/pseudo-integration tests featuring databases, you need the test data, and you need whatever harness or framework you’re working with to ensure that it doesn’t “leak” from one test to another.  Understandably, that has nothing to do with what Liquibase is.  Better, IMHO, to devote a tool like dbUnit or Arquillian Persistence to that aspect of the test system, and let Liquibase do what it does best, viz. set up the database in the first place.


Anyway, Liquiunit uses H2 for the in-memory database, Liquibase for the structural setup and dbUnit for the test data.  The last rule I’m going to throw in is one that also creates an EntityManager for lightweight JPA testing.


Best,

Laird


http://about.me/lairdnelson

Hello; I’ve recently put up my Liquiunit project at Github.


Liquiunit contains JUnit Rules for setting up H2 in-memory databases that can work well with parallel Maven Surefire/JUnit tests, Rules for running Liquibase on those databases, and Rules for running dbUnit on those databases as well.  All such rules can be nested, so, for example, you can set up a private per-thread in-memory H2 database whose structure is initialized by Liquibase and whose test data is managed by dbUnit, all while running your tests with parallel processes and threads.


Here’s the URL: http://ljnelson.github.io/liquiunit


I hope some folks find this helpful.


Best,

Laird



http://about.me/lairdnelson