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.
(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).
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.SHAREDnetwork. 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
https://github.com/quarkusio/quarkus/issues/21284
$upstream:21284$