Unit testing and the "constructors do nothing" rule

Introduction

Writing unit testing code is really easy.

It's not much more then writing some client code of the library you want to test and add some assert calls to check (test) if the code works as expected. With C# now we have lots of alternatives to do that.

But is it just that?

Not really!

Let's briefly look at some principles behind unit testing.

A unit test, as the name implies, should test just a unit a code. If it doesn't and it ends up depending on some other code then it becomes hard to tell why the test passes or not.
Also, depending on other code makes test hard to make repeatable. Just think about testing a method that depends on some database operation, now you should take care of maintaing database state over repeated calls to your test suite.

Being able to isolate units of code not also makes it more testable but also easier to work with and to refactor.

This post will try to explain some good practices to make your C# code more testable.

Constructors should do nothing

This is an important rule you should enforce if you want your code to be testable. It also makes it easier to enforce SRP (Single Responsibility Principle).
In the class constructor, objects should not be created, because if they are then your class becomes coupled to them and you are not able to inject testing objects during unit testing.

Lets jump to some sample code.

    public class StringsCalculator
    {
        public int Sum(string x, string y)
        {
            int xi = 0;
            int yi = 0;
            int result = 0;
            if (int.TryParse(x, out xi) && int.TryParse(y, out yi))
            {
                result = xi + yi;
            }
            else
            {
                throw new ArgumentException("Strings passed are not integers.");
            }
            return result;
        }
    }

This class StringsCalculator contains a method Sum that takes two strings and tries to sum them if the can be parsed as numbers. It clearly does two things, converting strings to integers and summing them. So if we want to test does separatly we should separate the two responsibilities. Perhaps separating the string conversion in a class StringToNumber:

    public class StringToNumber
    {
        public int Convert(string stringNumber)
        {
            int result = 0;
            if (!int.TryParse(stringNumber, out result))
            {
                throw new ArgumentException("String is not a number");
            }
            return result;
        }
    }

Thus we can refactor our StringsCalculator class:

    public class StringsCalculator
    {
        StringToNumber stringToNumber;

        public StringsCalculator()
        {
            this.stringToNumber = new StringToNumber();
        }
        
        public int Sum(string x, string y)
        {
            return stringToNumber.Convert(x) + stringToNumber.Convert(y);
        }
    }

This looks better, but what about our test:

        [Test]
        public void SumStringsNotTestable()
        {
            StringsCalculator ss = new StringsCalculator();
            int result = ss.Sum("2", "3");
            Assert.AreEqual(5, result);
        }

It tests our class but this way it tests also the StringToNumber class so it's really not "unit" testing.

So let's follow the "Constructors do nothing" rule by doing some refactoring.

First off let's separate the two classes by putting a interface between them. In Visual Studio we just need to right click on the StringToNumber class and choose Refactor->Extract interface... and name it IStringToNumber. Next we need modify the StringsCalculator constructor to accept a parameter of type IStringToNumber.

    public class StringsCalculator
    {
        IStringToNumber stringToNumber;

        public StringsCalculator(IStringToNumber stringToNumber)
        {
            this.stringToNumber = stringToNumber;
        }
        
        public int Sum(string x, string y)
        {
            return stringToNumber.Convert(x) + stringToNumber.Convert(y);
        }
    }

Mocking objects

Now we can refactor our test to instantiate the StringsCalculator object by passing to its constructor a mock object and not a StringToNumber object. To do this we can use one of the many mocking frameworks for .Net around. I chose the very nice RhinoMocks library, that's easy to use and quite complete. So here's our new test:

        [Test]
        public void SumStringsTest()
        {
            MockRepository mocks = new MockRepository();
            IStringToNumber stringToNumber = mocks.StrictMock();
            StringsCalculator ss = new StringsCalculator(stringToNumber);
            Expect.Call(stringToNumber.Convert("2")).Return(2);
            Expect.Call(stringToNumber.Convert("3")).Return(3);
            mocks.ReplayAll();
            int result = ss.Sum("2", "3");
            Assert.AreEqual(5, result);
            mocks.VerifyAll();
        }

As you can see we can instruct the RhinoMocks repository to expect two calls to the IStringToNumber. In this way we are able to verify the inner workings our our class, thus doing what is called white-box testing by calling the VerifyAll() method.

Constructor injection

Having all collaborators classes passed in as constructor parameters enables us to decouple nicely and test in isolation. But what about the client code using this classes, do they have to do lots of code to instantiate all those collaborators? Well there's a nice solution to this, dependency injection containers. In my case I'll use Unity, by using it to instantiate objects, client code doesn't have to prepare alkl those collaborators, Unity will take care of it, even in cascade if those collaborators themselves have other collaborators as constructor parameters. We can implement a integration test to verify our classes together:

        [Test]
        public void SumStringsUnityTest()
        {
            UnityContainer container = new UnityContainer();
            UnityConfigurationSection section =
                (UnityConfigurationSection)ConfigurationManager.GetSection("unity");

            section.Containers.Default.Configure(container);

            IStringToNumber stringToNumber = container.Resolve();
            StringsCalculator ss = new StringsCalculator(stringToNumber);
            int result = ss.Sum("2", "3");
            Assert.AreEqual(5, result);
        }

Unity configuration code could be conveniently located in a helper class.

So, to summarize, we can say: Constructors do nothing, all collaborators are passed in as parameters so we can mock them in unit tests and let a dependency injection mechanism compose them in client code.