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,