There are known issues with testing singletons and mocking s

Question

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

Adam Hurwitz · Answer

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

Ben Abramovitch · Answer

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 · Answer

Thanks Good to know < Ben Abramovitch> as I do have a test extension that resets the Repository mock after the tests

James Richardson · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

< 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