Hello all! I hope you’re doing great today! I am f...

# koin

[Tim Karagosian]

Hello all! I hope you’re doing great today! I am fairly new to Koin and DI and am trying to understand the testing side. Running individual tests and classes have no issues.

But when running all my test classes via Gradle task I’m fighting against KoinAlreadyStarted at GlobalContext errors on all my Test classes that implement a ViewModel from Koin. Has anyone experienced this before and can advise? Maybe even testing best practices could be helpful.

I’ve tried KoinRules and @Before/After for setup and cleanup too and I do not get a different error or result.

[Kibet Theophilus]

koin version?

[Tim Karagosian]

@Kibet Theophilus 3.5.3 is the version I’ve been using. I discovered after some tinkering that I may need to be abstracting my data differently to allow for testing. I just reworked my Home functionality into HomeScreen/ViewModel/Container/UiState and I believe I will have an easier time testing it as a result.

Here’s my GitHub for the project: https://github.com/timkaragosian1/2025TrainingApp

[Alexandru Caraus]

Looks good 👍

[Tim Karagosian]

@Alexandru Caraus I appreciate you taking a look! Do you mean I should be able to test it now with the abstracted way it is now? It’s a little different than my design for the SignInScreen and VM that allowed for instrument testing easily (and I still need to build unit tests there as well). My History classes are the old style I was trying to implement and could not get testing working at all for, but it lacks the same abstraction and organization.

I know once I get a solid working example or two then everything else will click in probably, I’m just struggling some in getting over the barrier to entry.

[Tim Karagosian]

As an update, I cannot test composables like unit tests and they must be in AndroidTest and run like instrument testing. Otherwise I get KoinAlreadyStarted and GeneralContext Exception errors.

The last time I was doing testing was the Java+XML days that allowed you to isolate and mock the methods and views to be able to test those UI methods. This is UI and code tied together with other classes handling the data and state so it is a different situation entirely.

[Alexandru Caraus]

To be honest in my current project we never needed that much koin in tests in practice, though I did use the idea in some of my personal projects before, and I had a rule where I would pass the modules i want to test and their config, some real, some fake, similar you have for the dispatcher. And I dont remeber having that problem, each test would be fresh setup.

[Alexandru Caraus]

You also could test in the androidTest the behaviour starting from viewmodel-repositories(usecase)-db in one shot, db can be real, api maybe fake, with some json output. And the main navigation flows with compose, with clicks and stuff.

[Alexandru Caraus]

And in unitTest keep for some complex function for if you need.

[Alexandru Caraus]

And also you can test composables, i think also in unit tests with something like snapshot testing, which will render the ui state you provide with @ComposePreview into a file which can be diffed on PR.

[Alexandru Caraus]

And that will have you covered solidly.

[Alexandru Caraus]

For the structure I would do, feature/login/(presentation/domain/data), someting like that.

[Alexandru Caraus]

On a big projects having things split in modules also helps, a lot

[Tim Karagosian]

Thank you much for this! And great to know that about employers. My upcoming employer has a desire to use Koin but currently does not have the knowledge or experience on how to use and test it appropriately to move from their current in-house DI and outdated code.

[Kibet Theophilus]

@Tim Karagosian Ideally you should abstract the composable to be taking the state and test it entirely on its own, then you can use verify to test the koin setup - https://insert-koin.io/docs/4.0/quickstart/android#verifying-your-app