Any input on how we can solve this? <https://stack...

# kotlintest

[Stian N]

Any input on how we can solve this? https://stackoverflow.com/questions/57972025/kotlintest-how-to-use-abstract-testcontainers-class

[thanksforallthefish]

one thing you want to consider is you will lose the transaction rollback if you move to kotlintest.

What I mean is, @Transactional (which you want to use around tests, so data modifications performed by the test are automatically rollbacked, otherwise you alter the data for subsequent tests and you become somehow dependent on the execution order) create a proxy around a method, but kotlintest does not really creates methods

[thanksforallthefish]

that being said, you can create a io.kotlintest.provided.ProjectConfig like

class ProjectConfig : AbstractProjectConfig() {
	override fun beforeAll() {
		start postgres
	}

	override fun afterAll() {
		stop postgres
	}
}

and I think it should work without needing to extend anything.

If I am not wrong, those two methods are run before/after the first/last test. It might get annoying with pure unit test and running them locally, as postgres would start for them too (but you can consider multiple test sourcesets if you are using gradle, one for regular tests and one for postgres dependent one)

[LeoColman]

You can use @Transactional at the class level, and set the isolation mode to instance per test

[LeoColman]

The Transactional context will be executed for every test

[LeoColman]

@Stian N What were your issues when using TestListener?

[sam]

We should add more docs on spring integration. I don’t think it’s clear how good KotlinTest works with spring

[Christian Dräger]

I think one problem here is TestContainers itself. Currently the @TestContainers annotation will not be inherited (there is an open issue redarding that and seems to be fixed within the next release)
see: https://github.com/testcontainers/testcontainers-java/issues/1843

as workaround you can annotate the parent class as well as the test class with @TestContainers until it's fixed.

[thanksforallthefish]

@sam, some more documentation and more advanced use cases would be welcome, it is not really easy (personally) to reverse engineer what is going on and do it correctly. The paradigm shift is quite big and since kotlintest can run junit5 tests it is worth the time invested