Hello! I'm trying to convert tests from JUnit -> Kotest for my Spring WebFlux + R2DBC application. Converting unit tests was easy enough using the Spring Extension, however, I'm not quite sure how to dynamically configure TestContainers for integration tests. I'm currently using this pattern to create a PostgreSQLContainer and configure Spring. How would I accomplish this using the TestContainers Extension? The main issue I'm experiencing is that

pgContainer

doesn't start until the first test is executed. However,

@DataR2dbcTest

tries to configure the Spring context before starting any tests, which obviously fails:

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [io.r2dbc.pool.ConnectionPool]: Factory method 'connectionFactory' threw exception; nested exception is org.springframework.boot.autoconfigure.r2dbc.ConnectionFactoryOptionsInitializer$ConnectionFactoryBeanCreationException: Failed to determine a suitable R2DBC Connection URL
Caused by: org.springframework.boot.autoconfigure.r2dbc.ConnectionFactoryOptionsInitializer$ConnectionFactoryBeanCreationException: Failed to determine a suitable R2DBC Connection URL

I'm going to play around with using the PostgreSQLContainer defined in

BaseIntegrationTest

, rather than defining one in my Spec.

I think the issue is that extensions run first

It configures everything that is required to use R2DBC: • Bootstrapping the database connection • Registering relevant beans, like

DatabaseClient

, so they can be used in Constructor injection • etc. (A bunch of 'magic', as with most Spring annotations.)

I guess my question is, what in that example is being confgured by that annotation

With the BaseIntegrationTest example, it starts the PostgreSQL container before any other part of Spring's context, and passes the container to

Initializer : ApplicationContextInitializer<ConfigurableApplicationContext>

, which runs before anything.

I'm trying to work this out on the example you pasted

Would there be any benefit to using the kotest extension in that case?

If people using junit are having to create testcontainers manually then I would imagine its easier to do that as well

Good to know. Thanks!

I guess DataR2dbcTest requires the instance up and runnning before the class is created, which is why in the other example from Java, they're doing it in the companion object init method

I guess DataR2dbcTest requires the instance up and runnning before the class is created,

Knowing Spring, there's likely a(n esoteric) method to defer this until after the class is created. That said, using a listener is much easier. This could likely be improved, but it starts/stops test containers only for integration tests and not unit tests.

Your listener could look for a custom annoation too if you didn't want to use supertypes

Excellent point, I hadn't considered that. It could just hook into

@DataR2dbcTest

directly.

Ok glad we got to a good place

@Richard Gomez I know this is an old thread, but how did you create your datasource? I'm following your example here but Spring is not picking up the JDBC URL. I have the following:

class TestDbContainer : PostgreSQLContainer<TestDbContainer>("postgres:13") {
    companion object {
        private lateinit var instance: TestDbContainer

        fun start() {
            if (!Companion::instance.isInitialized) {
                instance = TestDbContainer()
                instance.start()

                System.setProperty("DB_URL", instance.jdbcUrl)
                System.setProperty("DB_USERNAME", instance.username)
                System.setProperty("DB_PASSWORD", instance.password)
            }
        }

        fun stop() {
            instance.stop()
        }
    }
}

---
spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

Thanks!

@Victor Cardona I ended up switching to use a base class where Spring managed the lifecycle of the container and not TestContainers.

@DataR2dbcTest
@Import(DatabaseConfig::class)
internal class DatabaseIT : IntegrationTest, DescribeSpec({ ...

I wish I remembered why — I think it had something to do with the properties only being set/respected when called as a part of the

ApplicationContextInitializer

hook.

@Richard Gomez Thanks! I ended up having to do the same.