Hello! I'm trying to convert tests from JUnit -> Kotest for my Spring WebFlux + R2DBC applicatio...

# kotest

[Richard Gomez]

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.

R2dcTest.kt

[sam]

I think the issue is that extensions run first

[sam]

so you can't get the container to run before the spring setup

[sam]

I don't use spring, what does DataR2dbcTest do

[Richard Gomez]

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.)

[sam]

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

[sam]

is the the dbClient

[Richard Gomez]

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.

[Richard Gomez]

I don't think there's necessarily a simple relationship between annotation and class configuration.

[Richard Gomez]

What's important is specify the TestProperties, like the database URL, before Spring initializes everything.

[sam]

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

[sam]

the only member that spring knows about is the dbClient constructor parameter

[sam]

in the BaseIntegrationTest you linked to, they're creating the test container manually

[sam]

companion object {
        private val POSTGRES_CONTAINER = PostgreSQLContainer<Nothing>("postgres:latest")
        init {
            POSTGRES_CONTAINER.start()
        }
    }

[sam]

So I guess you could do the same thing

[Richard Gomez]

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

[Richard Gomez]

Admittedly, I'm not a Spring 'expert' either, so I'm trying to work these things out as well on my end.

I'm going to try testing more things, as I don't want to waste your time. I'll update this when I either hit a brick wall, or figure it out and have something to share.

[sam]

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

[sam]

and just ignore the test containers extension

[sam]

all the kotest extension does is call start and stop, like 2 lines of code

[sam]

https://github.com/kotest/kotest-extensions-testcontainers/blob/master/src/main/ko[…]io/kotest/extensions/testcontainers/StartablePerSpecListener.kt

[Richard Gomez]

Good to know. Thanks!

[Richard Gomez]

It seems that manually creating the container, outside of the test spec, is the way to go.

Either via Spring's @ContextConfiguration annotation initializer:

@DataR2dbcTest
@ContextConfiguration(initializers = [BaseIntegrationTest.Initializer::class])
internal class R2dbcTest(@Autowired private val dbClient: DatabaseClient) : DescribeSpec({

Or Kotest's ProjectConfig (based on Kotest#1649 and "Using Testcontainers with Micronaut and Kotest"):

object ProjectConfig : AbstractProjectConfig() {
    override fun beforeAll() {
        TestDbContainer.start()
    }

    override fun afterAll() {
        TestDbContainer.stop()
    }
}

@DataR2dbcTest
internal class R2dbcTest(@Autowired private val dbClient: DatabaseClient) : DescribeSpec({

[Richard Gomez]

Using the spec's before spec/container/test/any doesn't work. A custom extension or listener could work, provided they can run before the spec class is instantiated.

[sam]

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

[sam]

If you want something to hook into the project lifecycle, you can use ProjectListener (or in 5.0 ProjectExtension as well)

[Richard Gomez]

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.

example_kt.cpp

[sam]

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

[Richard Gomez]

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

[Richard Gomez]

Thanks, Sam. I think this covers all my needs.

[sam]

Ok glad we got to a good place

[Victor Cardona]

@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!

[Richard Gomez]

@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.

IntegrationTest.kt

[Victor Cardona]

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