With in-memory databases, you are testing against a different database than your production database.
Drawbacks of In-Memory Databases for Tests This can have a negative impact on the test reliability and the application implementation. With H2, we are testing against a different database than we use in production. The example implementations for Gradle and Maven can be found below. Just start the database container, run the tests and stop it afterward. Integrate the container management into the build.Use TestContainers and manage the database in your test code.Docker simplifies the management of database instances. Solution: Throw H2 and Fongo away and use a dockerized version of your real database instead.You skip the tests for some features completely.This may result in less effective, elegant, accurate or maintainable implementations. You change the application’s SQL code just to make it run in both the real and the in-memory database.They provide not the same features as the real database.Your application’s SQL may fail in production against the real database, although the h2-based tests are green. Using in-memory databases for tests reduce the reliability and scope of your tests.In this post, I explain my reservations and point out Docker as an alternative which can be easily used with TestContainers or within the Gradle/Maven build.
However, this comfort comes with severe drawbacks. Just start your tests and the H2 database will be up and running. You can test your code without having to worry about installing and managing a dedicated database server up front. Alternative: A Docker Container For The DatabaseĪt a first glance, in-memory databases (like H2 or Fongo) look like a good idea.Integration Tests in Production-like Environments.Drawbacks of In-Memory Databases for Tests.
#Drawbacks of using docker for mac software
Java Ecosystem, Kotlin, Engineering Management, Sociology of Software Development Don't use In-Memory Databases (H2, Fongo) for Tests
0 kommentar(er)
