Testing

TestContainers project can make your (integration) test life easier

Posted on by  
Tom de Vroomen

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?

Well, there is something to help you: the TestContainers project. With TestContainers you can startup your favourite database from a Docker container. TestContainers made a wrapper around docker to have an easy setup for your tests. And even better, is doesn’t only work with your favourite database, it works with any docker container you need in your test. Okay, I have to admit, the startup time for your test is longer in comparison with H2 or HSQLDB, but on the other hand you get a fully functional database instance.

Continue reading →

shadow-left