Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is a singleton class hard to test?

Tags:

java

singleton

Effective Java Item 3 (Enforce the singleton property with a private constructor or an enum type) notes that:

Making a class a singleton can make it difficult to test its clients, as it's impossible to substitute a mock implementation for a singleton unless it implements an interface that serves as its type.

For testing purposes, why is it not sufficient to instantiate the one singleton instance and test its APIs? Isn't that what a client would be consuming? The quote seems to imply that testing the singleton would involve a "mock implementation," but why is that necessary?

I've seen various "explanations" that are more or less rephrasings of the quote above. Can someone explain this further, preferably with a code example?

like image 912
coder123 Avatar asked Aug 12 '14 20:08

coder123


People also ask

Why is testing a singleton hard?

It's very difficult to write unit tests for code that uses singletons because it is generally tightly coupled with the singleton instance, which makes it hard to control the creation of singleton or mock it.

How do singleton affect testing?

If your singleton contains mutable state that cannot be reset between tests, then it will affect unit testing as the tests will need to be run in a specific order and the state accounted for. If your singleton contains state that changes of time, it will prevent you reliably running tests in parallel.

What are the disadvantages of the singleton class?

Disadvantages of a Singleton PatternUnit testing is more difficult (because it introduces a global state into an application). This pattern reduces the potential for parallelism within a program, because to access the singleton in a multi-threaded system, an object must be serialized (by locking).

Why singleton is not good?

By using singletons in your project, you start to create technical debt. Singletons tend to spread like a virus because it's so easy to access them. It's difficult to keep track of where they're used and getting rid of a singleton can be a refactoring nightmare in large or complex projects.


2 Answers

What if your singleton was performing operations on a database or writing data to a file? You would not want that occurring in a unit test. You would want to mock out the object to perform some operations in memory instead so you could verify them without having permanent side effects. Unit tests should be self contained and should not create connections to databases or perform other operations with outside systems that could fail and then cause your unit test to fail for an unrelated reason.

Example with pseudo-java (I'm a C# dev):

public class MySingleton {

    private static final MySingleton instance = new MySingleton();

    private MySingleton() { }

    public int doSomething() {
        //create connection to database, write to a file, etc..
        return something;
    }

    public static MySingleton getInstance() {
        return instance;
    }
}

public class OtherClass {

        public int myMethod() {
            //do some stuff
            int result = MySingleton.getInstance().doSomething();

            //do some other suff
            return something;
        }
}

In order to test myMethod we have to make an actual database call, file operation etc

@Test
public void testMyMethod() {
    OtherClass obj = new OtherClass();

    //if this fails it might be because of some external code called by 
    //MySingleton.doSomething(), not necessarily the logic inside MyMethod()

    Asserts.assertEqual(1, obj.myMethod());
}

If MySingleton was instead something like:

public class MyNonSingleton implements ISomeInterface {

    public MyNonSingleton() {}

    @Override
    public int doSomething() {
        //create connection to database, write to a file, etc..
        return something;
    }

}

you could then inject it as a dependency into MyOtherClass like this:

public class OtherClass {

    private ISomeInterface obj;

    public OtherClass(ISomeInterface obj) {
        this.obj = obj;
    }

    public int myMethod() {
        //do some stuff
        int result = obj.doSomething();

        //do some other stuff
        return something;
    }
}

then you can test like this:

@Test
public void TestMyMethod() {
    OtherClass obj = new OtherClass(new MockNonSingleton());

    //now our mock object can fake the database, filesystem etc. calls to isolate the testing to just the logic in myMethod()

    Asserts.assertEqual(1, obj.myMethod());
}
like image 72
mclaassen Avatar answered Sep 20 '22 05:09

mclaassen


Personally I think this statement is totally wrong, because it assumes that singleton is not replacable (mockable) for unit tests. On the contrary. In Spring's dependency injection, for example, singleton is actually the default model for DI components. Singletons and dependency injection are not mutually exclusive, which statement above somehow tries to imply.

I agree that anything that can't be mocked makes application more difficult to test, but there is no reason to assume singletons are less mockable than any other objects in your application.

What might be the problem, is the fact that singleton is one global instance and when it can be in too many different states, unit tests might show unpredictable results because of changing state of the singleton. But there are simple solutions to this - mock your singleton and make your mock to have less states. Or write your tests in such a fashion, that singleton is recreated (or reinitialized) before each unit test that depends on it. Or, the best solution, test your application for all possible states of the singleton. Ultimately, if reality requires multiple states, like, for example, a database connection (disconnected/connecting/connected/error/...), then you will have to deal with it regardless of whether you use singletons or not.

like image 35
lot Avatar answered Sep 19 '22 05:09

lot