Multiple bean definitions (Conflicts)

[wcarmon]

Your documentation says "latest bean wins"
(See https://insert-koin.io/docs/1.0/reference/koin-dsl/?#multiple-definitions)

The source code throws an exception if there are multiple beans:
see https://github.com/Ekito/koin/blob/0.9.1/koin-core/src/main/kotlin/org/koin/KoinContext.kt#L121

In case future readers face this,

My use case:
I want to override/replace/shadow specific beans with mocks/spies in my unit/integration tests.

My solution was to

• Register all the normal application beans (eg. via startKoin)
• Create a BeanDefinition instance for each mock/spy/fake
• Register them manually koin.beanRegistry.declare( theBeanDef , Scope.root())

[arnaudgiuliani]

If you want to reuse a module and override some definitions for your test, just make a module containing your new definitions and load modules in order: your app + your test module

The last module will override needed definitions

A bean is overriden when: same name, type and scope

You can match multiple bean for a given type if you use bind oeprators then

[arnaudgiuliani]

This project sample provides a test module: https://github.com/Ekito/koin-samples/tree/master/samples/android-weatherapp-mvvm/app/src/test/java/org/koin/sampleapp

[wcarmon]

I wish that worked! When I tried what you described, I get this exception: https://github.com/Ekito/koin/blob/0.9.1/koin-core/src/main/kotlin/org/koin/KoinContext.kt#L121

…

-W

On Wed, Apr 4, 2018, 12:58 Arnaud Giuliani ***@***.***> wrote: This project sample provides a test module: https://github.com/Ekito/koin-samples/tree/master/samples/android-weatherapp-mvvm/app/src/test/java/org/koin/sampleapp — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#100 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHEEtzaX6gI5IX7Y3MCmitU3ySqckQNAks5tlPuRgaJpZM4TBrpM> .

[arnaudgiuliani]

Do you have any sources to provide?

[arnaudgiuliani]

Could help me better understand your case

[wcarmon]

It's really hard to extract out a MWE for this.

I think I can illustrate using the sample app you provided...

Given this line...

You have testApp, which is a list (collection) of modules, and you pass that to startKoin in your TestApplication.

Unlike in this sample, My TestApplication had something like

startKoin( modulesForRealApp + aFewMockedInstancesInAModule )

There was overlap between the classes in modulesForRealApp and the classes in aFewMockedInstancesInAModule (eg. Same class, but in aFewMockedInstancesInAModule, I used Mockito.mock( MyClass ))

startKoin would fail with this exception.

My workaround was basically this

val koin = StandAloneContext.startKoin(
                list = RealApplication.koinModules.toList(),
                ...other params...
        )

val mocks: Collection<BeanDefinition<*>> = ...build-BeanDefinition-instances-manually...

mocks.forEach {
        koin.beanRegistry.declare(it, Scope.root())
}

[arnaudgiuliani]

If I understand, if you provide a dedicated mock module aFewMockedInstancesInAModule, it fails?
If you run it in a KoinTest, everything is still lazy until you pull any instance.

Or do you do something in some constructors?

[wcarmon]

Correct, startKoin fails when I add a dedicated module containing mock instances. (Only when 1 or more mocks instances replace a real instance. If there's no collision, there's no exception)

I did not use KoinTest. (I need to extend an unrelated class so extending KoinTest wasn't an option for me)

All of my injection is eager & constructor based (except my Android activities, which use val ... by inject())

[arnaudgiuliani]

I did not use KoinTest. (I need to extend an unrelated class so extending KoinTest wasn't an option for me)

KoinTest is just an interface. It help to tag a class and bring extenions on it.

All of my injection is eager & constructor based (except my Android activities, which use val ... by inject())

Original conflict comes from here. making it eager at start don"t help you, even more, if you use android context at start.

[wcarmon]

Of course you are correct about KoinTest being an interface. Clearly I didn't look into KoinTest at all.

As you mentioned, the root cause appears to be a choice of eager-injection versus lazy-injection.

I still prefer "immutable-after-construction" & eager injection, so I'll use the workaround above.

Thanks for the helpful information.