When migrating database schemas, you rarely get clean, predictable data. Legacy databases often have cryptic column names, partially backfilled fields, nullable values, or columns that are completely empty. That’s why you write custom Java JDBC mappers in the first place: to explicitly control how legacy database columns map to your target Java objects, rather than relying on automatic mapping that may not handle these inconsistencies correctly. But there’s a catch: standard unit tests can pass even when you completely forget to map a field. Because null == null, a missing mapping line looks identical to a column that is legitimately empty in your database.

There are those moments you wish you could just start up a real database or system for your (integration) test. In many tests I’ve written I used H2 or HSQLDB to have a data storage for my tests. It starts up quickly and almost supports everything you need to do your repository test or any other test needing data storage. But when your project progresses you start using other ways to store your data other than standard SQL or you use dialect specifics to create your database. This is the moment you discover H2 or HSQLDB is not supporting your database vendor specific features and you can’t get your test running. For example the support for PostgreSQL in H2 or HSQLDB isn’t great, using TIMESTAMP in a SQL script already makes H2 or HSQLDB break. Yes, there are workarounds, but you rather not apply them to keep your code clean and simple. This is the moment you wish it is cheap to start up a real database instance you can test against, so you’re sure your code works in your production environment. You could install the database software locally, make some scripts to initialise the database and clean up afterwards. Or you can make scripts to do this in a Docker container. But what if there’s something which makes this even cheaper to setup?