Introducing Micronaut Test Resources

Micronaut Test Resources simplifies testing of applications which depend on external resources, by handling the provisioning and lifecycle of such resources automatically. For example, if your application requires a MySQL server, in order to test the application, you need a MySQL database to be installed and configured, which includes a database name, a username and a password. In general, those are only relevant for production, where they are fixed. During development, all you care about is having one database available.

Here are a couple of traditional solutions to this problem:

1. document that a MySQL server is a pre-requisite, and give instructions about the database to create, credentials, etc. This can be simplified by using Docker containers, but there’s still manual setup involved.

2. Use a library like Testcontainers in order to simplify the setup

In general, using Testcontainers is preferred, because it integrates well with the JVM and provides an API which can be used in tests to spawn containers and interact with them. However, a better integration between Micronaut and Testcontainers can improve the developer experience in several ways:

• simplify the container lifecycle configuration by providing an opinionated framework-specific default way, making you think less of how to setup it in the individual tests : tests shouldn’t need to deal with the container lifecycle: we’d like to have test containers/resources management as transparent as possible.

• isolate it better from your application making it simpler to reason about dependencies (and transitive dependencies), not just for the developer, but for example tools enabling native mode as well: Testcontainers APIs "leak" to the test classpath, making it difficult to run tests in native mode. This is not a problem specific to the Testcontainers library though: many libraries are not yet compatible with GraalVM. Our solution makes it possible to use Testcontainers in native tests without the hassle of configuring it!

• enable support for "development mode", that is to say when you run the application locally (not the tests, the application itself) or even several distinct projects at once that can benefit from sharing access to the same running containers (for example, an MQTT client and a server may want to use the same container, even if they are individual projects living in distinct Git repositories).

The goal of Micronaut Test Resources is to achieve all of these at once:

• zero-configuration: without adding any configuration, test resources should be spawned and the application configured to use them. Configuration is only required for advanced use cases.

• classpath isolation: use of test resources shouldn’t leak into your application classpath, nor your test classpath

• compatible with GraalVM native: if you build a native binary, or run tests in native mode, test resources should be available

• easy to use: the Micronaut build plugins for Gradle and Maven should handle the complexity of figuring out the dependencies for you

• extensible: you can implement your own test resources, in case the built-in ones do not cover your use case

• technology agnostic: while lots of test resources use Testcontainers under the hood, you can use any other technology to create resources

In addition, Micronaut Test Resources support advanced development patterns, which are useful in the microservices era. As an example, it is capable of sharing containers between submodules of a single build, or even between independent projects, from different Git repositories! Say that you have 2 projects, one built with Gradle, the other with Maven, both needing to communicate using the same message bus: Micronaut is capable of handling this use case for you, making it extremely easy to test components interacting with each other!

Because of these constraints, we decided to use Testcontainers, because the library is just perfect for the job, but in an isolated process instead, as I’m going to describe below. Note that this solution is also 100% compatible with Testcontainers Cloud, which makes container provisioning even easier!