When I try to set isolationMode on Project level, it does not seem to count I have the following co...

# kotest

[huehnerlady]

When I try to set isolationMode on Project level, it does not seem to count

I have the following configuration

object KotestConfig : AbstractProjectConfig() {

  override val isolationMode = IsolationMode.InstancePerTest

  override fun listeners() = listOf(SpringListener)
}

But when I set a break point in a test I can see that isolationMode is actually null. Also tried to use the deprecated function, same result.
I can also see that the mode is not working as I have one test bleeding into the other.

With the listeners it seems to work as the Spring tests are running without having the spring listener added
Any idea what I am doing wrong?

[wasyl]

Is the config in io.kotlintest.provided package? Not sure how it exactly works after the auto-discovery changes, but it’s what we have and it seems to work

[sam]

You can put it anywhere now, and it's picking up the spring listener, so can't be an issue with it not finding the config class

[huehnerlady]

I do not have kotlintest as a package, I have just kotest.

I use kotlin version 1.4.10 and kotest version 4.2.5

[sam]

are you sure it's picking up the spring listener ?

[sam]

try changing object to class

[sam]

class KotestConfig : AbstractProjectConfig() {

  override val isolationMode = IsolationMode.InstancePerTest

  override fun listeners() = listOf(SpringListener)
}

[huehnerlady]

I am sure as with commenting out the listeners a lot of spring tests start failing

[huehnerlady]

and debugging into it worked as well

[huehnerlady]

hmm very odd, now even with the insolationMode I cannot stop the bleeding from happening. Do I have to do something special with DescribeSpec?

[sam]

I've looked over the code and cannot see why isolation mode wouldn't be picked up. What do you mean by bleeding

[huehnerlady]

well I declare a “every” code for a mockk in one test and I can see the response of that mock in the other test

[sam]

do you have a simplified sample you can post

[wasyl]

@huehnerlady Be aware that InstancePerTest is different from InstancePerLeaf, which I find the most intuitive and consistent with plain JUnit. PerTest runner will run each test, even a container, in a separate Spec instance. PerLeaf runner will create an instance per lowest-level container, one that typically contains assertions (e.g. it in a DescribeSpec). Perhaps you could post a sample test with print statements and output that you expect vs what you see

[huehnerlady]

ok so I found out it is not actually test bleeding, BUT the shouldBe seems not to work for lists?

I recreated a sample

describe("tests") {
      it("should fail") {
        listOf("someString") shouldBe emptyList()
      }
    }

In my opinion this test should fail, but it actually passes. That made me think there must be some mock return bleeding over as I was not thinking shouldBe would be the problem.

So is shouldBe not the right thing to use for comparing 2 lists?

[huehnerlady]

Be aware that InstancePerTest is different from InstancePerLeaf, which I find the most intuitive and consistent with plain JUnit.

@wasyl thanks this is a very good point, I think I want to use InstancePerLeaf actually here 🙂 I will try this next

[wasyl]

This fails for me as expected

[wasyl]

[huehnerlady]

hmm for me it does not, how can that me? 🤔

[huehnerlady]

did you use kotest 4.2.5 and kotlin 1.4.10?

[huehnerlady]

I have included the following in my gradle file:

io.kotest:kotest-assertions-core-jvm
io.kotest:kotest-extensions-spring
io.kotest:kotest-framework-engine-jvm
io.kotest:kotest-property-jvm
io.kotest:kotest-runner-junit5-jvm

[wasyl]

Oh, I’m using Kotest 4.3.0, Kotlin 1.4.10 and org.junit:junit-bom:5.7.0

[huehnerlady]

oh there is a 4.3.0?

[wasyl]

Yep it’s not tagged in Github though

[wasyl]

https://kotest.io/changelog/

[wasyl]

I think you’re hitting https://github.com/kotest/kotest/issues/1727 which was fixed in 4.2.6

[huehnerlady]

ah it seems my error was actually fixed in 4.2.6

[huehnerlady]

😉

[huehnerlady]

sorry for the confusion, I was confused by that method and that was what I changed last, but yeah isolationMode seems to work fine, feel very stupid now, haha, sorry for that

[huehnerlady]

yes with the new version it works as expected. I watch the releases on github but I guess I need to look into a different way of getting noified by new versions 😉

[sam]

I'll tag it in github now

[huehnerlady]

oh thanks thats great 🙂