using spring, hibernate and scala, is there a better way to load test data than dbunit?

Here are some things I really dislike about dbunit:

1) You cannot specify the exact ordering the inserts because dbunit likes to group your inserts by table name, and not by the order you define them in the XML file. This is a problem when you have records depending on other records in other tables, so you have to disable foreign key constraints during your tests... which actually sucks because these foreign key constraints will get fired in production while your tests won't be aware of them!

2) They seem hellbent on forcing you to use an xml namespace to define your xml... and I honestly can't be bothered to do this. I like the data.xml without any namespace. It works. But they are so hellbent on deprecating it.

3) Creating different xml files is hard o开发者_运维百科n a per test basis, so it actually encourages creating data for your entire app. Unfortunately, this process is a little bloated too once the data grows in size and things get inter tangled. There has got to be a better way to split up your test data into chunks without having to copy/paste a lot of the test data across all of your tests.

4) Keeping track of id references in a big xml file is just impossible. If you have 130 domain classes, it just gets bewildering. This model simply does not scale.

Is there something less bloated and better in the Spring/Hibernate space? db unit has worn out its welcome and I'm really looking for something better.

---

For 1) See if you can define your constraints as deferrable (Oracle docs), the check will be deferred until the commit of the transaction.

For the others, consider using a Factory approach, ie, using a Factory class that knows how to create objects and insert them in the DB for testing purposes. This may defeat some of the purpose of testing, since you rely on your insert/update code for the test to work.

I've found that the factory approach works ok, if you keet it simple enough.