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?