https://kotlinlang.org logo
Join Slack
Powered by
I'm having some issues with the migration, notably...
# kotest
m
I'm having some issues with the migration, notably with the Koin integration. The KoinExtension registers a 
beforeAny
that filters 
TestType.Test
, I previously declared my DI mocks in 
beforeEach
so that I didn't have to do that extra check. However, with Kotest 5.0, 
beforeEach
gets called before 
beforeAny
in TestExtensions, which causes my mocks to fail because Koin hasn't started yet. I wonder if the order in TestExtensions should be changed again, as I'd expect the outer scopes to evaluate before inner scopes, thus container → any → each.
Additionally, the KoinExtension hasn't apparently been updated to 5.0.0 yet, as using the 
KoinLifecycleMode.Root
causes a 
NoSuchMethodException
.
s
Outer scope listeners will fire first
but perhaps what you're seeing here is the beforeAny of the inner firing before the beforeEach of the inner
m
I should've been more clear, I'm observing that beforeEach (which I register in the spec constructor) is called before the beforeAny that the KoinExtension uses.
Previously, that wasn't the case
s
Do you have an example layout ?
the test contents don't matter, just the structure
and the callbacks
m
Copy code
class Sample : DslDrivenSpec(), StringSpecRootScope, KoinTest {

    lateinit var mockedProperty: SessionRepository

    init {
        beforeEach {
            mockedProperty = declareMock()
        }

        "Some test case" {

        }
    }

    override fun extensions() = listOf(
        KoinExtension(
            modules = listOf(appModule, authModule),
            mockProvider = { clazz -> mockkClass(clazz) },
        ),
    )
}
That's an example of what I'm doing right now
The problem is that beforeEach with the declareMock is executed before the KoinExtension is run
s
Why are you extending dsl driven spec and root scope ?
m
Because my base class for tests does a few other things, just copy pasted this sample. It also fails when extending 
StringSpec
normally.
s
ok
I makes sense that beforeAny should run before beforeEach since it's more general
But the trouble with trying to order beforeXX operations is that however you do it, someone somewhere will want it the other way.
Let me try to think of a better solution.
Probably moving the KoinExtension to be an interceptor will do the trick, then it will always run first.
m
But the trouble with trying to order beforeXX operations is that however you do it, someone somewhere will want it the other way.
True, it was just a bit surprising that it changed after the upgrade. But I agree a more general solution would be preferable.
Probably moving the KoinExtension to be an interceptor will do the trick, then it will always run first.
Is that something that I can do or does it have to be changed in the extension?
s
Yeah in the extension
But I can do that now and release a 5.0 compatible release
It won't take long assuming it works
m
That would be very appreciated, thank you!
Thanks for the update, looks promising! Gonna try it out tomorrow.
s
How did you know 🙂
Was about to tell you
m
Actually, I randomly opened the GitHub and saw you push like a minute ago. Very random and a bit scary 😆
s
haha
m
But yeah, I'll give it a go tomorrow / once it's published.
s
if you use latest (remember to add snapshots maven repo)
and it works, I will publish 1.1.0
m
Ok, I'll try and report back!
✅ 1
I think the default is still the per-test mode though?
s
yes, I just wanted to make it clear you could change it
the docs are somewhat lacking
I'm not even sure myself what the KoinTest interface does
m
Ah ok, just because the tests explicitly use 
Test
in the second sample, thought it should maybe outline the root mode there.
KoinTest
is just a simple marker to allow resolving Koin components
It's actually just an alias to 
KoinComponent
Might do other things too, but I haven't come across those yet
s
Ah ok
So it's needed? I don't know koin very well
I've updated the docs to reverse the KoinLifecycleMode example
m
It's necessary to use declareMock
If I find the time, I can open a PR for the docs tomorrow and make them a bit clearer
s
Yeah taht would be awesome
m
Update: new version works perfectly!
s
awesome
m
When are you planning to release it to the stable channel then?
s
can do it now
m
Nice. I just opened a PR for the docs. Conceptually, it was fine, but the code sample had a small mistake and I made the lifecycle mode option a bit clearer.
Open for suggestions though.
s
looks good
m
Thanks for the merge!
s
1.1.0 released, takes 30 minutes to show up
✅ 1
2 Views
Open in Slack
PreviousNext
Powered by