https://kotlinlang.org logo
Join Slack
Powered by
Hi, We are currently migrating to kotest 6. We sa...
# kotest
h
Hi, We are currently migrating to kotest 6. We saw that the InstancePerLeaf is deprecated. Could someone please motivate why this has to go? It says there are some edge cases that are not defined. Which edge cases are those? Would it not be possible to document those edge cases - or resolve them - and leave that setting in place? We tried to move InstancePerLeaf -> InstancePerRoot, but now the tests are really bloated up and a lot harder to read.... So our idea is to stay on InstancePerLeaf and hope that maybe you change your mind? 😓
o
In order to explore options: Could you share an example where your migration led to bloated code?
h
well we always have to wrap everything in 
beforeTest
On top of that if we have an object that gets manipulated by the test, we have to change val to var and instantiate it in 
beforeTest
Copy code
lateinit var something: MyObject

beforeTest {
something = MyObject("will be changed in test)
}
in comparison to
Copy code
val something = MyObject("will be changed in test)
I try to find the time to create a sample project, but thought this is a first quick response 🙂
o
I get the idea. To think about it and not miss the point, a single test source (could be faked) in its shape before and after the migration would be just good enough.
I have prepared a Gist with two alternatives you could use. Does that help?
s
@Oliver.O would you be able to share a gist which covers a test with instance per leaf mode with what it is supposed to be after migrating it to Kotest v6 please ? that can be very helpful for us, to estimate the effort needed to migrate out tests which we have thousands of them.
o
Isn’t that what my above Gist shows? The first source requires Kotest < 6.0 while the other two variants should work with Kotest 6.0.
t
Could someone please motivate why this has to go?
you can find the reason from this commit message; Kotest team seemed necessary to rework existing Kotest engines and isolation modes to achieve more robust concurrency with simple implementation https://github.com/kotest/kotest/commit/65263415b83087f34b938d7b462139d8c8b02bc5#diff-679342fbe030cf57a6512c2c94d[…]cd0b688d341b9fa84b14a496dcec7c4e
s
@Oliver.O from what I see the gist is about InstancePerTest -> WithoutIsolation, I'm looking for InstancePerLeaf -> WithoutIsolation, specially in Complex test with BehaviourSpec
o
My above Gist was so simple that it actually fit the 
InstancePerLeaf
case. The general principle is: If your test needs a fresh context for each leaf or test container, create the context on the required level (in my case, it was the leaf) and create an extension function that "injects" the context into your test case (
suspend Context.() -> Unit
). In my above case, I had created a new variant for the 
test
function that does so. Having said that, I'm not aware of a clean migration solution that would work in all cases. I always found the Kotest mechanism to re-instantiate specs too complicated to use safely, so I never did. Maybe something like this work might for you:
Copy code
import io.kotest.core.spec.style.BehaviorSpec
import io.kotest.core.spec.style.scopes.BehaviorSpecWhenContainerScope
import io.kotest.matchers.shouldBe

class MyBehaviorSuite : BehaviorSpec() {
    private class MyClass(var myProperty: Int = 1)

    private class MyContext {
        val myObject: MyClass = MyClass()
    }

    init {
        given("something") {
            `when`("it matters") {
                then("one", MyContext()) {
                    myObject.myProperty shouldBe 1
                    myObject.myProperty += 10
                    myObject.myProperty shouldBe 11
                }

                then("two", MyContext()) {
                    myObject.myProperty shouldBe 1
                    myObject.myProperty += 20
                    myObject.myProperty shouldBe 21
                }
            }
        }
    }
}

suspend fun <Context> BehaviorSpecWhenContainerScope.then(
    name: String,
    context: Context,
    action: suspend Context.() -> Unit
) = then(name) {
    context.action()
}
h
For me I would like to just have a new instance per Leaf/test (We use describe spec, so it would be per 
it
), and not have to think about what I need to do in order to achieve the instance per 
it
... I appreciate that you might want to remove the current instancePerLeaf/Test, but maybe there could be a new isolationMode that covers the complete isolation of tests, so people do not have to deal with test bleeding (which is the case at the moment) The context solution works, my solution works too, but it does make the tests more complex and less readable than the 
InstancePerLeaf
does/did
o
I wasn't involved in recent framework changes. Regarding readability/complexity then: • Yes, formerly you could rely on the framework re-instantiating your class, which was convenient (and easy to reason about in simple cases). • The downside is that the magic behind the scenes is hard to reason about (and control), especially if there are multiple container levels involved, and more so if these container levels themselves contain assertions. Multiple levels of initialization must re-run just to provide a clean setup for the next test. That's complex. On the other hand, with the newer solutions (like mine): • You need to declare a separate context object, which is two additional lines of code (the custom test function can be re-used). • The tests themselves do not change, so the main test code does not suffer from bloat. • Control flow is explicit and simple, you can see exactly when the context initializes. No magic, you always know where to set a breakpoint if something is suspect. Does that make sense?
h
I do understand. From my point of view - a users point of view, is it a loss of convenience though, hence we hoped it would be readded in a different way again how do you add mocked services, like eg. with mockk in this gist?
o
I don't use mocks, I use fakes where necessary.
😅 1
I guess it's about time to write an article "Say goodbye to dinosaur testing patterns which no longer fit today's Kotlin ecosystem". For mocks, some insights can be found here: https://amzn.github.io/app-platform/testing/#mocks
😅 1
❤️ 1
l
Thanks for the gists! Would a similar solution be possible when 
myObject
would be modified in the 
given
and 
when
blocks as well? I want the modifications from 
given
/ 
when
to flow into the nested 
then
blocks, but the modifications inside the first 
then
should not leak to the other 
then
instance (and similarly for parallel 
when
etc.).
o
Actually, there is an initiative which made this work with TestBalloon in this Addon collection, and an integrated implementation of that feature is targeted for TestBalloon as well:
Copy code
{
    object {
        var a: Int = 1
        val b: Int = 2
    }
}.generatingFixtureFor {
    test("one") {
        it.a++ //and we can even modify them in one test
        println("a=${it.a}, b=${it.b}") //a=2, b=2
    }
    test("two") {
        //without affecting the other!
        println("a=${it.a}, b=${it.b}") //a=1, b=2
    }
}
Could this inspire you to make something like this work with Kotest?
l
Yes
But how about nesting?
Copy code
"given a viewmodel was created" - {
    val viewModel = MyViewModel()
    viewModel.uiState shouldBe EmptyState

    "when the customer scanned the wrong code then show error dialog" - {
        viewModel.scanCode(wrongCode)
        viewModel.uiState shouldBe ErrorDialog

        "when the customer dismissed the dialog then close it" {
            viewModel.onDismissErrorDialog()
            viewModel.uiState shouldBe EmptyState
        }

         "when customer selected manual input then show manual input dialog" - {
            viewModel.onManualInputSelected()
            viewModel.uiState shouldBe ManualInput

            "when the customer entered correct code manually then show success" {
                // ...
            }
        }
    }

    "when the customer scanned the correct code then show success" {
        viewModel.scanCode(correctCode)
        viewModel.uiState shouldBe Success
    }
}
Would your example also support such nested hierarchies, where the SUT (viewModel here) can be modified at any nesting level?
o
In TestBalloon: Yes, and by default. All of its non-leaf nesting levels are test suites, and you can generate variants at every level. In Kotest, it's probably possible as well, but could be more complicated, as Kotest has separate structures: specs at the top, then contexts, then tests.
l
ok, thank you for the explanation!
Is TestBalloon production ready?
o
It is robust, already used in production (see its doc site), but at version 0.7.1, which means that some API details may still change. Also, the IDE plugin is still evolving (see issue list). So as always, whether that's production-ready for you depends on your use case. But that's probably better discussed in #C09FQGG85EC.
thank you color 1
If you find out how to make the above work with Kotest, it could be useful to post it here to let people know!
l
Yes, definitely will post my solution.
👍 1
123 Views
Open in Slack
PreviousNext
Powered by