Unit testing with singletons

Question

I have prepared some authomatic tests with the Visual Studio Team Edition testing framework. I want one of the tests to connect to the database following the normal way it is done in the program:

string r_providerName = ConfigurationManager.ConnectionStrings["main_db"].ProviderName;

But I am receiving an exception in this line. I suppose this is happening because the ConfigurationManager is a singleton. How can you work around the singleton problem with unit tests?

---

Thanks for the replies. All of them have been very instructive.

Answer 1

Have a look at the Google Testing blog:

• Using dependency injection to avoid singletons
• Singletons are Pathological Liars
• Root Cause of Singletons
• Where have all the Singletons Gone?
• Clean Code Talks - Global State and Singletons
• Dependency Injection.

And also:

• Once Is Not Enough
• Performant Singletons

Finally, Misko Hevery wrote a guide on his blog: Writing Testable Code.

Answer 2

You can use constructor dependency injection. Example:

public class SingletonDependedClass
{
    private string _ProviderName;

    public SingletonDependedClass()
        : this(ConfigurationManager.ConnectionStrings["main_db"].ProviderName)
    {
    }

    public SingletonDependedClass(string providerName)
    {
        _ProviderName = providerName;
    }
}

That allows you to pass connection string directly to object during testing.

Also if you use Visual Studio Team Edition testing framework you can make constructor with parameter private and test the class through the accessor.

Actually I solve that kind of problems with mocking. Example:

You have a class which depends on singleton:

public class Singleton
{
    public virtual string SomeProperty { get; set; }

    private static Singleton _Instance;
    public static Singleton Insatnce
    {
        get
        {
            if (_Instance == null)
            {
                _Instance = new Singleton();
            }

            return _Instance;
        }
    }

    protected Singleton()
    {
    }
}

public class SingletonDependedClass
{
    public void SomeMethod()
    {
        ...
        string str = Singleton.Insatnce.SomeProperty;
        ...
    }
}

First of all SingletonDependedClass needs to be refactored to take Singleton instance as constructor parameter:

public class SingletonDependedClass
{    
    private Singleton _SingletonInstance;

    public SingletonDependedClass()
        : this(Singleton.Insatnce)
    {
    }

    private SingletonDependedClass(Singleton singletonInstance)
    {
        _SingletonInstance = singletonInstance;
    }

    public void SomeMethod()
    {
        string str = _SingletonInstance.SomeProperty;
    }
}

Test of SingletonDependedClass (Moq mocking library is used):

[TestMethod()]
public void SomeMethodTest()
{
    var singletonMock = new Mock<Singleton>();
    singletonMock.Setup(s => s.SomeProperty).Returns("some test data");
    var target = new SingletonDependedClass_Accessor(singletonMock.Object);
    ...
}

Answer 3

You are facing a more general problem here. If misused, Singletons hinder testabiliy.

I have done a detailed analysis of this problem in the context of a decoupled design. I'll try to summarize my points:

1. If your Singleton carries a significant global state, don’t use Singleton. This includes persistent storage such as Databases, Files etc.
2. In cases, where dependency on a Singleton Object is not obvious by the classes name, the dependency should be injected. The need to inject Singleton Instances into classes proves a wrong usage of the pattern (see point 1).
3. A Singleton’s life-cycle is assumed to be the same as the application’s. Most Singleton implementations are using a lazy-load mechanism to instantiate themselves. This is trivial and their life-cycle is unlikely to change, or else you shouldn’t use Singleton.