Allow to use Testcontainers with @AutoConfigureTestDatabase

[snicoll]

Follow-up of this limitation reported on SO, it would be nice if users were able to configure the URL that @AutoConfigureTestDatabase uses. Right now if they want a specific dialect or any other extra parameter, they have to switch off our support to configure things manually.

[snicoll]

We've spent some time discussing this feature and we're willing to investigate a support of testcontainers rather which would provide all the necessary flexibility.

[snicoll]

Now that we have r2dbc support, we should also take that use case into account so that the ConectionFactory points to a database replaced via this mechanism.

[wilkinsona]

I've been experimenting a little bit in this area. I have a test class like this:

@JdbcTest
@AutoConfigureTestDatabase(replace = Replace.NONE)
@Testcontainers(disabledWithoutDocker = true)
@Import(SomeRepository.class)
@Sql(scripts = "data.sql")
class SomeRepositoryTests {

	@Container
	private static final PostgreSQLContainer<?> postgresqlContainer = new PostgreSQLContainer<>("postgres:13.2")
			.withDatabaseName("example");

	@Autowired
	private SomeRepository someRepository;

        // @Test methods

I've then got a context customizer factory and a context customizer that turns each JdbcDatabaseContainer field into a DataSource bean:

/**
 * A {@link ContextCustomizerFactory} that returns a
 * {@link JdbcDatabaseContainerContextCustomizer} when {@link JdbcDatabaseContainer} is on
 * the classpath and the test class has one or more static fields of that type.
 *
 * @author Andy Wilkinson
 */
class JdbcDatabaseContainerContextCustomizerFactory implements ContextCustomizerFactory {

	@Override
	public ContextCustomizer createContextCustomizer(Class<?> testClass,
			List<ContextConfigurationAttributes> configAttributes) {
		if (ClassUtils.isPresent("org.testcontainers.containers.JdbcDatabaseContainer", testClass.getClassLoader())) {
			Set<Field> jdbcDatabaseContainerFields = new HashSet<>();
			ReflectionUtils.doWithFields(testClass, (field) -> {
				if (Modifier.isStatic(field.getModifiers())
						&& JdbcDatabaseContainer.class.isAssignableFrom(field.getType())) {
					ReflectionUtils.makeAccessible(field);
					jdbcDatabaseContainerFields.add(field);
				}
			});
			if (!jdbcDatabaseContainerFields.isEmpty()) {
				return new JdbcDatabaseContainerContextCustomizer(jdbcDatabaseContainerFields);
			}
		}
		return null;
	}

}

/**
 * {@link ContextCustomizer} that registers a {@link DataSource} bean for each
 * {@link JdbcDatabaseContainer} field in the test class.
 *
 * @author Andy Wilkinson
 */
class JdbcDatabaseContainerContextCustomizer implements ContextCustomizer {

	private final Set<Field> jdbcDatabaseContainerFields;

	JdbcDatabaseContainerContextCustomizer(Set<Field> jdbcDatabaseContainerFields) {
		this.jdbcDatabaseContainerFields = jdbcDatabaseContainerFields;
	}

	@Override
	public void customizeContext(ConfigurableApplicationContext context, MergedContextConfiguration mergedConfig) {
		for (Field field : this.jdbcDatabaseContainerFields) {
			JdbcDatabaseContainer<?> container = (JdbcDatabaseContainer<?>) ReflectionUtils.getField(field, null);
			BeanDefinition definition = new RootBeanDefinition(DataSource.class,
					() -> DataSourceBuilder.create(context.getClassLoader()).url(container.getJdbcUrl())
							.username(container.getUsername()).password(container.getPassword()).build());
			((BeanDefinitionRegistry) context.getBeanFactory()).registerBeanDefinition(field.getName(), definition);
		}
	}

}

I think this isn't too far off. I'd prefer it if @AutoConfigureTestDatabase(replace = Replace.NONE) wasn't necessary. If this context customization was done in Boot itself, we'd also need some way of opting in as it'd be too much for it to always happen. Perhaps a @TestDatabase annotation on the test's postgresqlContainer field?

The above isn't hugely Testcontainers-specific and I wonder if there may be some mileage in some general support for adding beans to the context or setting properties in the environment that are derived from static fields in a test class. It could be useful for #27151 as well, for example, with a mechanism that allows the JdbcDatabaseContainer to DataSource bean or org.neo4j.harness.Neo4j to spring.neo4j.* properties capability to be contributed.

[vpavic]

This was perhaps made obsolete by #35253?

[wilkinsona]

Yes, I think it was. Thanks, @vpavic.