Home » DevOps » Running complex project setups with Testcontainers

About Sebastian Daschner

Sebastian Daschner is a self-employed Java consultant and trainer. He is the author of the book 'Architecting Modern Java EE Applications'. Sebastian is a Java Champion, Oracle Developer Champion and JavaOne Rockstar.

Running complex project setups with Testcontainers

In a lot of my #testing content, I’ve been showing how to run projects locally, for example by using Docker containers. In this video, I’m showing how to build up a complex project setup using Testcontainers, while keeping a flexible and efficient development workflow.

My goal is to separate the life cycles of my system / acceptance tests from the test environment’s life cycle, in order to allow for quick turnarounds and to re-use my test scenarios in different scopes. In this way, this shows how to build up what I’d consider a local test environment that is optimized for developer productivity.

To try it out yourself, you can find the source code on GitHub: coffee-testing

The example contains the following coffee-shop system:

The three containers (black in the picture) are started by Testcontainers, but separately from my test scenarios:

public class CoffeeShop {

    static Network network = Network.newNetwork();

    static GenericContainer<?> barista = new GenericContainer<>("rodolpheche/wiremock:2.6.0")
            .withExposedPorts(8080)
            .waitingFor(Wait.forHttp("/__admin/"))
            .withNetwork(network)
            .withNetworkAliases("barista");

    static PostgreSQLContainer<?> coffeeShopDb = new PostgreSQLContainer<>("postgres:9.5")
            .withExposedPorts(5432)
            .withDatabaseName("postgres")
            .withUsername("postgres")
            .withPassword("postgres")
            .withNetwork(network)
            .withNetworkAliases("coffee-shop-db");

    static GenericContainer<?> coffeeShop = new GenericContainer<>(new ImageFromDockerfile("coffee-shop")
            .withDockerfile(Paths.get(System.getProperty("user.dir"), "../coffee-shop/Dockerfile")))
            .withExposedPorts(8080)
            .waitingFor(Wait.forHttp("/q/health"))
            .withNetwork(network)
            .withNetworkAliases("coffee-shop")
            .dependsOn(barista, coffeeShopDb);

    @Test
    void startContainers() throws IOException {

        Startables.deepStart(coffeeShop, barista, coffeeShopDb).join();

        String coffeeShopHost = coffeeShop.getHost();
        int coffeeShopPort = coffeeShop.getMappedPort(8080);
        String baristaHost = barista.getHost();
        int baristaPort = barista.getMappedPort(8080);

        writeDotEnvFile(coffeeShopHost, coffeeShopPort, baristaHost, baristaPort);

        String uri = "http://" + coffeeShopHost + ":" + coffeeShopPort + "/index.html";
        System.out.println("The coffee-shop URLs is: " + uri);
        System.out.println("\nContainers started. Press any key or kill process to stop");
        System.in.read();
    }

}

As shown in the video, you can run the example in your IDE or via the command line:

mvn -Dtest=com.sebastian_daschner.coffee_shop.CoffeeShop test

The reason why these classes are called CoffeeShop and CoffeeShopDev, respectively, is that they won’t be executed via Maven Surefire per default, since they don’t contain the sequence Test.

Network configuration

Since Testcontainers urges us to have a non-fixed setup, here with regards to port bindings, we need to reconfigure our URLs for in test scenarios and for manual access. Our test environment has been started in a separate JVM, which is why the Testcontainers code has no access as to which dynamic ports have been assigned.

We could find out the actual ports by using docker ps or similar methods:

 
gt; docker ps CONTAINER ID IMAGE [...] STATUS PORTS cad0913a4787 coffee-shop:latest Up 2 seconds 0.0.0.0:49230->8080/tcp, :::49230->8080/tcp a1dd67f758e5 rodolpheche/wiremock:2.6.0 Up 19 seconds 8081/tcp, 0.0.0.0:49228->8080/tcp, :::49228->8080/tcp aa3759e70103 postgres:9.5 Up 19 seconds 0.0.0.0:49229->5432/tcp, :::49229->5432/tcp 1113ebda12b4 testcontainers/ryuk:0.3.1 Up 20 seconds 0.0.0.0:49227->8080/tcp, :::49227->8080/tcp

However, still there would be manual effort involved, to find out and configure the URLs, such as localhost:49228, :49229, and :49230, each and every time. Thus, we use a way to automatically re-configure our system tests. Our CoffeeShop class will write the port configuration into a .env file, which will be read from our system test, via MicroProfile Config, here with Smallrye as the implementation:

Config config = ConfigProvider.getConfig();
String host = config.getValue("coffee-shop.test.host", String.class);
String port = config.getValue("coffee-shop.test.port", String.class);
return UriBuilder.fromUri("http://{host}:{port}/orders")
        .build(host, port);

The code on GitHub and the video gives you the full picture of how the URLs are configured. Per default, the values from a microprofile-config.properties is taken, or the properties in .env with a higher priority.

# META-INF/microprofile-config.properties
coffee-shop.test.host=localhost
coffee-shop.test.port=8001
barista.test.host=localhost
barista.test.port=8002
# .env, written by CoffeeShop class
COFFEE_SHOP_TEST_HOST=localhost
COFFEE_SHOP_TEST_PORT=49230
BARISTA_TEST_HOST=localhost
BARISTA_TEST_PORT=49228

This enables us to start up the environment, and use the system tests in a very fast and flexible way, as shown in the video.

Quarkus remote-dev mode

It also works to run Quarkus’ dev mode in containers, as remote-dev mode. My second Testcontainers example, that you find in the class CoffeeShopDev, starts up the coffee-shop application in a way that allows to be accessed by quarkus:remote-dev. This is really handy for us, since we don’t have to start & stop our application while we’re coding.

The CoffeeShopDev class will output the mvn command with the correct port, similar to:

mvn quarkus:remote-dev -Ddebug=false -Dquarkus.package.type=mutable-jar \
  -Dquarkus.live-reload.url=http://localhost:49230 -Dquarkus.live-reload.password=123

Shortening the test turnaround time

As one more bonus, I’m showing how to even shorten the initialization & waiting time of our tests, by (mis-)using quarkus:dev for our system test project, which in fact is not even a Quarkus project. This is the same approach that I’ve been showing in a previous video.

We can run the example, similar to what is shown in this video, as follows:

cd coffee-shop-st/
mvn quarkus:dev -Ptest \
  -Dquarkus.test.exclude-pattern='.*\.CoffeeShop​|​.*\.CoffeeShopDev​|​.*UITest'

Trying it out yourself

You can find the source code on GitHub: coffee-testing

Found the post useful? Subscribe to my newsletter for more free content, tips and tricks on IT & Java:

Success! Now check your email to confirm your subscription.

Published on Java Code Geeks with permission by Sebastian Daschner, partner at our JCG program. See the original article here: Running complex project setups with Testcontainers

Opinions expressed by Java Code Geeks contributors are their own.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

 

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

 

and many more ....

 

Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions

 

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments