Optimizing Spring Integration Tests at Scale

3.5. Reusable Static Docker Container Bean

Instead of creating TestContainer-managed Docker containers as beans for each Spring context, use a specialized static bean declaration:

@TestConfiguration
public class LocalStackS3TestConfiguration {
    private static LocalStackContainer localStackS3;

    // override destroy method to empty to avoid closing docker container
    // bean on closing Spring context
    @Bean(destroyMethod = "")
    public LocalStackContainer localStackS3Container() {
        synchronized (LocalStackS3TestConfiguration.class) {
            if (localStackS3 == null) {
                localStackS3 = new LocalStackContainer(DockerImageName.parse("localstack/localstack:4.6.0"))
                        .withServices(LocalStackContainer.Service.S3);
                localStackS3.start();
            }
            return localStackS3;
        }
    }
}

Note that the destroyMethod annotation parameter should be overridden to avoid closing it on context close.

3.6. Lazy Initialization of Database Containers

If an application has a single database, it’s not that critical. But if there are several DataSources accessing different schemas, it makes sense to start database containers only on demand (lazily). As in many tests, these initializations will be simply redundant (rare integration tests are using all possible DataSources). Technically, it can be implemented this way:

• don’t start the TestContainers Container object immediately
• create a wrapping DataSource object that will start the underlying container on the very first getConnection() call

We can base our implementation on Spring DelegatingDataSource (it should also be Closeable to delegate bean shutdown):

public class LateInitDataSource extends DelegatingDataSource implements Closeable {
    private final Supplier<DataSource> dataSourceSupplier;

    public LateInitDataSource(Supplier<DataSource> dataSourceSupplier) {
        // SingletonSupplier: call dataSourceSupplier.get() not more than once
        this.dataSourceSupplier = SingletonSupplier.of(() -> {
            DataSource dataSource = dataSourceSupplier.get();
            setTargetDataSource(dataSource);
            return dataSource;
        });
    }

    @Override
    public void afterPropertiesSet() {
        // no op to skip getTargetDataSource setup
    }

    @Override
    protected DataSource obtainTargetDataSource() {
        return dataSourceSupplier.get();
    }

    @Override
    public void close() throws IOException {
        DataSource targetDataSource = getTargetDataSource();
        if (targetDataSource instanceof AutoCloseable) {
            try {
                ((AutoCloseable) targetDataSource).close();
            } catch (IOException e) {
                throw e;
            } catch (Exception e) {
                throw new IOException("Error while closing targetDataSource", e);
            }
        }
    }

    @Override
    public String toString() {
        return "LateInitDataSource{" + ", delegate=" + getTargetDataSource() + '}';
    }
}

Then, we also need to declare the DataSource beans:

@Bean
public DataSource dataSource(PostgreSQLContainer<?> container) {
    // lazy late initialization
    return new LateInitDataSource(() -> {
        LOGGER.info("Late initialization data source docker container {}", container);
        // start only on demand
        container.start();
        return createHikariDataSourceForContainer(container);
    });
}

3.7. Bad Practice: Fixed Ports

Using fixed port numbers (as we usually configure in production) is convenient for integration testing; however, it limits possible parallelization of test execution. For example, it prevents multiple test classes in the same module or in multiple modules from being executed simultaneously. We can observe test server initialization issues like:

Caused by: java.io.IOException: Failed to bind to address 0.0.0.0/0.0.0.0:8080 (address already in use)

Instead of configuring fixed ports for HTTP, GRPC, and TestContainer ports:

@SpringBootTest(webEnvironment = WebEnvironment.DEFINED_PORT)

Prefer using WebEnvironment.RANDOM_PORT:

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
// will inject actual dynamic port
@LocalServerPort
private int port;

For the case of manual Server Socket initialization, use server socket port 0 (zero); it will auto-assign a random available server port. Configure the test clients accordingly.

3.8. Bad Practice: Container Is Not a @Bean

The Docker container managed by TestContainers should have lifecycle management by Spring. Avoid declarations like:

@TestConfiguration
public class DockerDataSourceTestConfiguration {
    @Bean
    public DataSource dataSource() {
        // not a manageable bean!
        var container = new PostgreSQLContainer("postgres:9.6");
        container.start();
        return createDataSource(container);
    }

    private static DataSource createDataSource(JdbcDatabaseContainer container) {
        var hikariDataSource = new HikariDataSource();
        hikariDataSouce.setJdbcUrl(container.getJdbcUrl());
        ...
        return hikariDataSource;
    }
}

Instead, declare the Container as a bean and inject it as a DataSource creation parameter:

@TestConfiguration
public class DockerDataSourceTestConfiguration {
    // will be terminated with Spring context
    @Bean(initMethod = "start")
    public PostgreSQLContainer postgreSQLContainer() {
        return new PostgreSQLContainer("postgres:9.6");
    }

    @Bean
    public DataSource dataSource(PostgreSQLContainer postgreSQLContainer) {
        return createDataSource(postgreSQLContainer);
    }

    // ...
}

3.9. Bad Practice: ExecutorService Is Not Properly Shut Down

There is a similar situation with ExecutorService created during class initialization. It should be properly managed; otherwise, eventually, the runtime can have lots of active threads that complicate test failure analysis, increase the resource consumption, and may lead to confusing failure messages in test execution logs for failing scheduled tasks in such executors that are still active. To address the problem, add missing @PreDestroy methods:

@Service
public class DefaultScheduler {
    private final ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(16);

    public void scheduleNow(Runnable command, long periodSeconds) {
        scheduler.scheduleAtFixedRate(command, 0L, periodSeconds, TimeUnit.SECONDS);
    }

    // to avoid thread leakage in test execution
    @PreDestroy
    public void shutdown() {
        scheduler.shutdown();
    }
}

This simple approach will also have a positive effect on a proper application shutdown.

4. Let’s Revisit Standard Test Execution Behavior

It’s possible to maximize the optimization of resource consumption during test execution. When the test engine starts the suite, we already know the list of test classes. This way, we can predict the exact moment when the Spring context stops being used and eagerly close it:

On the time diagram, we can see that the same context is used for Test1IT, Test2IT, and Test7IT. It means that after Test7IT, we can terminate the context, releasing all resources. The same goes for Test3IT, Test4IT and Test8IT.

Let’s mix it with the second optimization — reorder test execution to sequentially execute tests that share the same context:

Now, at any moment in time, we have no more than one active Spring context. This way, the test suite needs the minimal possible amount of resources (like CPU and memory). This will also reduce the load on the Docker environment that manages TestContainer Spring beans.

To support this behavior, we have to implement:

• suite test classes reordering
• auto-closing of the Spring context

Spring Framework cannot control the test class order; it’s a responsibility of the test engine (like TestNG or JUnit). JUnit 5 supports test reordering via a specialized listener org.junit.jupiter.api.ClassOrderer. The implementation of such a reordering listener is a part of the spring-test-smart-context project.

The class implementing the ClassOrderer should be in the classpath of the module with tests so that it will be auto-discovered via junit-platform.properties. The ordering logic is based on the calculated MergedContextConfiguration object of the test class.

To auto-close the Spring context, use SmartDirtiesContextTestExecutionListener or base your implementation on it.

4.1. Easy-to-Use Solution

Such logic can be implemented in the project, but it’s easier to use a simple plug-in library that will be auto-discovered via the classpath. There are three simple steps.

First, we need to add a library to the test classpath:

<dependency>
    <groupId>com.github.seregamorph</groupId>
    <artifactId>spring-test-smart-context</artifactId>
    <version>0.14</version>
    <scope>test</scope>
</dependency>

Or for Gradle, we add:

testImplementation("com.github.seregamorph:spring-test-smart-context:0.14")

Then, remove from tests (especially parent test classes) the @DirtiesContext annotations if it was used, or replace al uses of it with declarations:

@TestExecutionListeners(listeners = {
    SmartDirtiesContextTestExecutionListener.class,
})

Optionally, enable INFO logging for com.github.seregamorph.testsmartcontext logger to see more details.

Sample log output during test execution can look like:

There, we can see the estimated number of tests to execute and how many unique configurations they use, and we can understand how Spring reuses existing context between different tests.

4.2. Implicit Benefits

Besides all the described advantages of using smart test ordering and context closing, there are a few more. When the test engine executes all tests in a single thread, closing all allocated resources on context close, it’s way easier to inspect JVM monitoring to analyze heap and thread leakages:

As we can see here, the chart of active thread numbers has drops – these are Spring context closings. But there is an obvious ascending trend in the number of threads, which signals the thread leakages. A similar heap dump chart may also highlight if we’ve missed closing allocated resources properly.

5. Conclusion

Inspecting and optimizing Spring integration tests can significantly reduce the amount of required resources, such as CPU and memory, and it may stabilize test execution. Also, with fewer resources allocated, the test execution will always be faster. There’s a simple explanation for this: The system will not lose resources on redundant Docker container management, thread pools, and so on.

Addressing such problems with integration tests can also enhance the proper graceful shutdown cycle of the application, making deployments more seamless.

In rare cases, it can even help to find leakages affecting production code!