Connect the MockServer testcontainer to the DevService testcontainer Docker network in the integration test

Description

As already asked in the question on Stackoverflow, I would like to connect a testcontainer (MockServer) to the Docker network that was started by Quarkus DevService in the integration test. I would like to explain my problem using this graphic:

My application (wolkenschloss / nubes / cookbook) imports data from an external source. In the test, the deployment artifact is to be tested in the Docker container (-Dquarkus.container-image.build = true). The data (the imported recipe) is persisted in a MongoDB. The MongoDB is managed by the Quarkus DevService in the integration test. This starts the Docker container of MongoDB with the option --net [random-network-name]. Quarkus generates a connection string for MongoDB with a host alias for access to the database. So far everything is very comfortable.

Now the external data source is to be simulated by a MockServer. Since the application runs in a Docker container, localhost cannot be used because locahost is now the Docker container. A connection from the Docker container to the MockServer must be established. To do this, the MockServer must release its port to the host (development computer or CI server) and the ImportService must be given an IP address of the host (not 127.0.0.1) as the import source. Determining the host IP address can sometimes lead to unexpected results if several adapters are installed (or none at all). Alternatively I tried to connect the MockServer testcontainer to the Network.SHARED network. However, this is not the network that Quarkus DevServices is using. In summary, the procedure is anything but comfortable.

In my example, I am currently using Wiremock without a container, but I would prefer to run MockServer in a test container in the same Docker network as the MongoDB and the Quarkus application to be tested. For the test, it should be transparent whether the application is running in a Docker container or not.

I consider this scenario to be quite common. External systems that cannot be controlled should also be mocked in an integration test: [Integrated Tests Are A Scam}) https://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam)

(And if I had one more wish: A little more control over the life cycle of the container would be nice. For example, restarting the database container before each test, even if it takes a little more time).

Implementation ideas

No response

[einarjohnson]

hi again. I think I have figured out what the problem was. Like you say @eijckron, I needed to use the hostname aliases. I was also incorrectly using @TestProfile instead of @QuarkusTestResource. Thanks for all the help here guys, really appreciate the input.

[eijckron]

@einarjohnson Just to be sure, when running the application as a docker image the application container should use the hostname of mock-server (ALIAS = “mockserver” in my example code), mysql and kafka containers. I assume dev services fix this for you for mysql and kafka. In this case the application code runs within the docker network while your test code does not.

From your test code however you have to connect to a mapped port on localhost.

This differs from the run application from jar scenario since then the mock-server, mysql and kafka containers are accessed through their mapped port on localhost both from the application code and the test code.