Reduce the need for @AutoConfigureTestDatabase(replace=NONE) when using a test-provided database

[wilkinsona]

If a test class is using @ServiceConnection to create a test-specific DataSource, @DataJpaTest or any other sliced-test annotation that uses @AutoConfigureTestDatabase will replace it with an embedded database due to its default replacement policy of ANY. I believe the same problem will occur with @DynamicPropertySource so this problem isn't particularly new. That said we may not be able to fix it in maintenance releases, it'll depend on the nature and complexity of any fix. Assigning to 3.1.x for now.

[quaff]

That's #35125 trying to fix.

[wilkinsona]

Unfortunately, I don't think #35125 is the right approach. As I said when closing the PR, I don't think the location of where connection details are defined is a strong enough signal to decide whether or not the database should be replaced. A user could have defined their own JdbcConnectionDetails that should be replaced. Alternatively, they could have used @DynamicPropertySource and then we'd want to keep the database defined by DataSourceAutoConfiguration.

[quaff]

@wilkinsona What about skip replacing DataSource if bean org.springframework.boot.testcontainers.service.connection.ServiceConnectionAutoConfiguration is present?

	if (registry.containsBeanDefinition("org.springframework.boot.testcontainers.service.connection.ServiceConnectionAutoConfiguration") ) {
		logger.info(
						"Skip replacing DataSource bean with embedded version due to @ServiceConnection is using");
		return;
	}

[wilkinsona]

Thanks for the idea. Unfortunately, I don't think we can assume that the presence of ServiceConnectionAutoConfiguration guarantees that the replacement should not happen or that its absence guarantees that the replacement should happen. For example, as I said above, there's also the @DynamicPropertySource case where someone may not be using spring-boot-testcontainers but they still don't want any replacement to happen.

I think we need a general purpose way of having more control over the replacement, but I don't yet know what that looks like. I think anything that relies on specifics will be too brittle.

[philwebb]

I have a possible solution to this at https://github.com/philwebb/spring-boot/tree/gh-35253, but it feels risky for a bug fix. Especially since adding @AutoConfigureTestDatabase(replace=Replace.NONE) is a pretty easy workaround.

I'm also not totally sure about how we should detect service connections. There's a FIXME in that code that I'd like to get opinions on from others in the team.