The Horrible Dilemma of Dockerising Databases for Testing
When working with database client code you have essentially got 4 options for testing:
- Mock out the entire dao layer – so your DB code isn’t tested – which is great when it’s entirely autogenerated and trustworthy
- Mock the DB driver – an often messy implementation-driven rewrite-backwards of the client code just to make tests go green – proving not much
- Use a fake in memory database – H2 is a great example – it simulates the database, but isn’t the real thing
- Install the database via docker – which tests the client code for real
On this scale, the middle points are where the pain lies. Mocking the DB driver is horrible (we do it) and only provides some useful test capabilities. It doesn’t provide ZERO, so there are cases for it, but it proves a limited amount.
Mocking the whole DAO is best… but then who tests the DAO? Will it really work in production?
Skipping all DB tests until integration testing is an option… but is it fail fast?
In memory databases were great until docker came along.
This is the Dilemma
In memory fake databases only prove so much. If you have docker available, and something like Testcontainers to manage it, then why would you use in memory fake databases?
But for many RDBMS installations, once you factor in the real life things you want to include in your simulation like schemas, reference data, stored procedures and triggers… the bootup time for your tests is measurable in minutes.
With docker we’re slowed down, without it we’re faster and blinded to some areas of our real-life environment.
The Answer?
Honestly… no idea. Keep oscillating between extremes of doing it and having slow tests, or not doing it and having naive tests.
We definitely need to include dockerised databases in our builds, but where in the process is still something I want to investigate some more.
Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: The Best and Worst of Times Opinions expressed by Java Code Geeks contributors are their own. |
I’m doing the Rails approach. Since testing more and more goes into the direction of the developer machine and current wisdom is to make environments look the same as much as possible plus the almost inescapable fact that there invariably is that little nook or cranny where database specific traits shine through (primary keys and generators come to mind) I just bite the bullet and develop against the target database.