There are known issues with testing singletons and...

# feed

[James Richardson]

There are known issues with testing singletons and mocking static methods. It's a pattern to be approached with care.

[Adam Hurwitz]

Thanks @James Richardson! Another dev. echoed the feedback on static methods in my article post thread above. I'll take a look at avoiding this library method from being called to begin with.

I will look into the Singleton point more.

I see there is one thread here on the topic: https://stackoverflow.com/questions/8256989/singleton-and-unit-testing

[Ben Abramovitch]

As long as you have a way to "reset" the singleton they should be testable. I haven't had any problems.

You should be able to do that with DI where you reset it in the @Before or @After o some other destructive method. It is an extra step you need to be aware of and always deal with though, otherwise tests may randomly fail from remembered state.

[Adam Hurwitz]

Thanks! Good to know @Ben Abramovitch, as I do have a test extension that resets the Repository mock after the tests.

[James Richardson]

JUnit creates an instance of the test class while running each test. This is a great design choice. It means that everything in your test will have fresh state. however, static state (and I include singletons in this) is shared across the whole JVM (ok, classloaders can do some stuff, but in general theres only one copy of this state) - resetting it is error prone - you may not know what state needs to be reset, and/or you may do it wrong - it is also conceptually problematic - a test is not supposed to know about the implementation of the classes it tests, only the observable effects.

[James Richardson]

in addition, having shared static state in a system means that testing cannot be done in parallel in the same JVM, else the tests will interfere with each other. its a way that the test system is telling you that there may be an issue.

[Ben Abramovitch]

When I was saying reset, I didn't mean go singletonVariable.value = null. I meant a method to completely wipe the singleton from existence so it can create a new one.

In the tear down destroying the instance doesn't really go against the test knowing about state

[Ben Abramovitch]

E.G In Koin you can do this in @After

unloadKoinModules()

For each test which would then return a new single instance the next time the test is run, but it might do this automatically as well (I'm new to koin testing) . I imagine that's what the stopKoin call actually does in a test.

[James Richardson]

it is a shame that the android docs talk about such design patterns - Singletons, static state, Service Locators and nulls are generally avoided wherever possible in testable, reliable code

[James Richardson]

once you start to have static state in a codebase it is terribly difficult to get rid of it - one singleton can reference another and so on...

[Daniel]

The fun of debugging randomly failing ui (or unit) tests is worth it though.. (sarcasm)...

its just a fact, someone will at some point forget to reset static state. And then you have tests failing because they are ordered in a certain way.

For example you have tests failing in ci but they work on your machine on first glance. Fun!

[Adam Hurwitz]

@James Richardson, Love the constructive feedback above! To conclude, would implementing Dagger2 to create the Repository and Database instances be one proposed refactor to avoid the issues with using Singletons above?