-1

Many moons ago I built a utility library that wraps the JDBC libraries with classes that allowed for functional-style approaches. I've used this library for my own purposes for many years. I've long wanted to make this into a proper open-source project. I started at one point and then got busy with life. With the new language features of Java 8, I'm re-energized around doing this. I know RDBMs isn't cool anymore (yes, I am a dinosaur) but that's part of why I want to get this off of my chest. I also think it might be possible to extend the abstractions to other non-RDBMs technologies.

One thing that I'm getting stuck on is the right way to build unit tests for this. I really want to do this in a test-first manner but it doesn't always come naturally to me so I am looking for advice.

Generally I don't consider reaching out to a database to be in the realm of unit-testing. But in this case, the only thing this library does is wrap interactions with the database. I could do some sort of mocking setup and that might add some value but the (perceived) complexity of doing that is a little daunting. My sense is that I will get bogged down with that, bored and end up dropping this again. The other approach I used in my previous stab at this was to use Apache Derby in embedded mode. This allowed for things to be self contained and I could easily stand-up and tear-down the tests. There are various quirks between databases when it comes to JDBC but I don't think that's a problem here. Part of the point of this is attempt to normalize these kinds of things as much as can be done.

Does the approach of using the embedded database make sense for this kind of project? Is the mocking option easier than I think it will be. Is there another approach that I should consider?

2

1 Answer 1

2

The challenge with testing a library like this is isolating the part that actually makes the query. I'm not sure how your application is structured, but I usually attempt to test everything that happens before the actual database code. That said, there are a couple tools you may want to try:

  • JOOQ: which looks like it can mock different dialects of SQL. (I have not used this, so I can't comment on specifics)
  • Just use a SQLITE3 memory bound database or something similar

The idea is that you want the state to be completely reset before each unit test.

If you have an intermediate format that is used to assemble the final query, I would test that the intermediate format is set up as expected, then the resulting query text is also as expected. Work one testable layer at a time.

1
  • The isolation of the query is a big part of the API but I'm not (at this point) considering trying to normalize or generate query strings. My focus is on working with the results. JOOQ which is the MockConnection provider referenced in the comments on the question looks like it might fit the bill. The javadocs even say "avoiding the round-trip of using an actual in-memory test database, such as Derby, ...". I think I might even be able to use test ids as the 'query' which really fits well.
    – JimmyJames
    Apr 25, 2017 at 21:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.