Is there a dbunit-like framework that doesn't suck for java/scala?

I just released a groovy DSL based framework called pedal-loader available via [github](

[To see links please register here]

). Documentation [here](

[To see links please register here]

).

It allows you to work with JPA entity level abstraction directly. Since it is a groovy script, you can use all of the groovy constructs.

To insert rows into a table backed by a JPA entity called Student, with fields (not database columns, but mapped fields) called id, name and grade, you would do something like this:

allStudents = table(Student, ['id', 'name', 'grade']) {
row 1, 'Joe', Grade.A
rowOfInterest = row 2, 'John', Grade.B
}

Grade is an enum in the Student class that is mapped to the database column (perhaps using JPA 2.1 @Convert annotation). allStudents is a list that will hold the rows and rowOfInterest is a reference to a particular row. These properties (allStudents and rowOfInterest) become available to your unit test.

The situation of DBUnit is indeed sometimes frustrating. Some of the problem are solved from [Marc Philipp](

[To see links please register here]

) with [dbunit-datasetbuilder](

[To see links please register here]

), specially if you combine it with the [validator](

[To see links please register here]

), which is in a very early stage. You can see it in action at [SZE](

[To see links please register here]

).

Disclaimer: All referenced github-resources are maintained by me.

I just released a library called JDBDT (Java Database Delta Testing) that
you may use for database setup and validation in software tests.

Have a look at

[To see links please register here]

Best,
Eduardo

Another vote for wrapping DBUnit with a modern library to improve usability and conciseness. My choice is [database-rider][1], which makes DBUnit a breeze to use and even supports JUnit 5 as demonstrated in the following example:

@RunWith(JUnitPlatform.class)
@ExtendWith(DBUnitExtension.class)
@DBUnit(cacheConnection = true, cacheTableNames = true)
class TestInstrumentQueryService {

private ConnectionHolder connHolder = () -> EntityManagerProvider.instance("my-jta-unit").connection();

@DBRider
@DataSet("datasets/instrumentIds.yml")
void testFindInstrumentById() {

InstrumentQueryService iqs = new InstrumentQueryService(EntityManagerProvider.em());

Instrument instr = iqs.findInstrumentById(InstrumentIdType.TICKER_BBG, "AAPL");
assertEquals(100, instr.getId());
}
}

Notice how this allows leveraging (concise) YAML testing data sets seamlessly (YAML not XML, though I'm lead to believe that DBUnit actually supports those natively).

[1]:

[To see links please register here]

I'm not aware of any real alternative to DbUnit and none of the tools mentioned by [@Joe][1] are in my eyes:

- [Incanto][2]: not DB agnostic
- [SQLUnit][3]: a regression and unit testing harness for testing database stored procedures (that's not what DbUnit is about)
- [Cactus][4]: a tool for In-container testing (I fail to see where it helps with databases)
- [Liquibase][5]: a database migration tool (doesn't load/verify data)
- [ORMUnit][6]: can initialize a database but that's all
- [JMock][7]: doesn't compete with DbUnit at all

That being said, I've personally used DbUnit successfully several times, on small and huge projects, and I find it pretty usable, especially when using [Unitils][8] and its DbUnit module. This doesn't mean it's perfect and can't be improved but with decent tooling (either custom made or something like Unitils), using it has been a decent experience.

So let me answer some of your points:

> 1) The simplest format to write and get started is deprecated. They want you to use formats that are bloated. Some even require xml schemas. Yeah, whatever.

DbUnit supports flat or structured XML, XLS, CSV. What revolutionary format would you like to use? By the way, a DTD or schema is not mandatory when using XML. But it gives you nice things like validation and auto-completion, how is that bad? And Unitils can generate it easily for you, see [Generate an XSD or DTD of the database structure][9].

> It could be better if dbunit helped in disabling foreign key constraints as part of their framework automatically, but they don't do this. They do keep track of dialects... so why not use them for this? Ultimately, all of this does is force the programmer to waste time and not get up and testing quickly.

They are waiting for your patch.

Meanwhile, Unitils provides support to handle constraints transparently, see [Disabling constraints and updating sequences][10].

> 3) XML is a pain to write. I don't need to say more about this. They also offer so many ways to do it, that I think it just complicates matters. Just offer one really solid way and be done with it.

I guess pain is subjective but I don't find it painful, especially when using a schema and autocompletion. What is the silver bullet you're suggesting?

> 4) When your data gets large, keeping track of the ids and their consistent/correct relationships is a royal pain.

Keep them small, that's a know [best practice][11]. You're going against a known best practice and then complain...

> Also, if you don't work on a project for a month, how are you to remember that user_id 1 was an admin, user_id 2 was a business user, user_id 3 was an engineer and user_id 4 was something else? Going back to check this is wasting more time. There should be a meaningful way to retrieve it other than an arbitrary number.

Yes, task switching is counter productive. But since you're working with low level data, you have to know how they are represented, there is no magic solution unless you use a higher level API of course (but that's not the purpose of DbUnit).

> 5) It's slow. I've found that unless hsqldb is used, it is painfully slow. It doesn't have to be. There are also numerous ways to mess up its configuration as it is not easy to do "out of the box". There is a hump that you must go through to get it working right. All this does is encourage people to not use it, or be pissed of when they do start to use it.

That's inherent to databases and JDBC, not DbUnit. Use a fast database like H2 if you want things to be as fast as possible (if you have a better agnostic way to do things, I'd be glad to learn about it).

> 6) Probably the most annoying thing is that the first entry must include ALL the values - even null placeholders - or future rows won't pick the columns that you actually specified.

Not when using Unitils as mentioned in presentations like [Unitils - Home - JavaPolis 2008][12] or [Unit testing: unitils & dbmaintain][13].

> Anything out there to satisfy me, or should I become the next framework developer of a much better database testing framework?

If you think you can make things better, maybe contribute to existing solutions. If that's not possible and if you think you can create the killer database testing framework, what can I say, do it. But don't forget, ranting is easy, coming up with solutions using your own solutions is less so.


[1]:

[To see links please register here]

[2]:

[To see links please register here]

[3]:

[To see links please register here]

[4]:

[To see links please register here]

"Retired"
[5]:

[To see links please register here]

[6]:

[To see links please register here]

[7]:

[To see links please register here]

[8]:

[To see links please register here]

[9]:

[To see links please register here]

[10]:

[To see links please register here]

[11]:

[To see links please register here]

[12]:
[13]:

[To see links please register here]