Saturday, April 10, 2010

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.

11 comments:

  1. For me, changing code to be testable is... detestable!

    In fact, you have to define "Unit". What is a unit?

    In your case, "Business" unit is to sum two numbers. Everything else is undercover. As we do black box testing, we do not care about anything else.
    Why introducing another class and another interface we do not "business" care, but only "testable" care?

    ReplyDelete
  2. Hi Ludovic,

    Thanks for taking time to read my post and to write a comment!

    "Unit" in unit testing is a unit of code, not of business rules.

    But... in this case you could even argue that the two classes are responsible of two different concerns. One contains the logic behind converting strings to numbers and the second one the logic behind summing the two.

    Anyway keep in mind this is just a sample, no one would really write that code for some real application. Like no one would really write a method that outputs "Hello world!" to the user...

    Making code testable doesn't necessarily mean you have to refactor, most of the times you can design your classes to work like that from the beginning. Having the testability concern in mind helps writing code that works better. Code that adheres to SOLID principles http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 is code that is more testable.

    The ideas behind the "Constructors do nothing" rule are well defined in Google guidelines for writing testable code, I strongly suggest to take a look at them at http://misko.hevery.com/code-reviewers-guide/ and to download the PDF file linked there. Very nice indeed!

    ReplyDelete
  3. Yes I know all that stuff.
    But, we write code for business needs and not for code needs...
    Thus, why not be driven by 'Business' unit testing?

    Then if you need to structure your application, for managing complexity, for updatability, readability or any kind of ...ity: that's fine. You structure your code with good practices and then, you need 'code' unit testing too ('business' sub-unit testing? :-)).

    ReplyDelete
  4. Software is becoming more and more a complex thing, users expect more and requirements grow.

    So managing complexity is the heart of developing software. Applying the "constructor do nothing rule" seems a big investment, but it's really not and it yields high dividends.

    ReplyDelete
  5. Hi Ludovic, Giorgo.

    I think it's whether this is subject to test-first development or to some kind of after-the-fact testing to verify some sort of (then black box) functionality. Both of you are right, but you seem to have different scenarios in mind.

    When doing test-driven development, then all the post's statements apply - writing testable code IS a business value in itself, not or hardly testable code generally is sloppy code (And anyway: how could you practically develop such code with TDD?).

    But if you test after the fact (maybe against a third-party component, or you chose to have a black-box testing strategy for some reason), then 'refactoring' code only to make it testable clearly is a smell, and it even is no possible choice in most cases.

    Personally, I always followed the rule 'C'tors must not contain any business logic' intuitively, but it's nice to now see it written down explicitly...

    Regards
    Thomas

    ReplyDelete
  6. I can see TDD is going to be a regular practice of development. Even for any existing complex system, when it comes to enhancement or modification to support, it becomes a nightmare if there are many complex classes exists which are not testable.

    I have seem people scared of touching legacy code in the fear of breaking something. I would rather prefer to right testable evidences of any functionality to reduce regular testing overhead to ensure things are working as per expectation.

    Now we have many nice frameworks for mocking and unit testing which helps to get these things quickly so why not...

    ReplyDelete
  7. Thanks Sujit Singh for reading my blog and commenting.

    In fact the techniques and the tools that are available today make it really easy to do TDD.

    And making code testable is not just about testing, it's about making design decision about code that help in encapsulating logic nicely. So the code is not only testable but also maintainable and this means it can grow without collapsing under the weight of big balls of mud...

    ReplyDelete
  8. Dependency Injection by configuration ASP.NET MVC Training ASP.NET MVC Training The pattern is similar to the Service locator pattern as defined by Martin Fowler. ASP.NET MVC Online Training MVC Online Training class implementing ISessionFactory Online MVC Training India Chennai Online MVC Training India

    ReplyDelete
  9. To learn Dot Net Training in Chennai Dot Net Training in Chennai LINQ, you should have through understanding on Func Delegate Dot net Training Institutes in Chennai Dot Net Training Institutes in Chennai . To Know Func Delegates, you should know delegates. .Net Training in Chennai .Net Training in Chennai . To know delegates, you should get trained in Anonymous method and anonymous objects. .net training online India

    ReplyDelete

  10. Enter Key Office Setup, after purchasing MS Office from visit www.office.com/setup, sign in to your Microsoft account then enter product key for Office Setup

    ReplyDelete