Unit testing smells and best practices

One of the most difficult task I know as a software engineer is to write good unit test. Of course multi-threading and distributed systems are also challenging but in this post I want to share some of the good and bad things I've learning doing unit testing over the last decade.

In a series of posts I'll cover mistakes I made in the past and good techniques I learned along the way. Come back often as this list will grow over time.

The smells

• The non-public class
• The class constructor is not easy to call
• The method is not public

Unit testing smells: The method is not public

A recurring pattern emerge often when unit testing, you find an interesting method you want to test but that method is private. Of course you could call that method through other public methods on the class but it might not be easy to cover all cases. This usually is a design smell for a Single Responsibility Principle violation. More on this later.

For now, to properly test the private method we have the following options:

• Use reflection
• Change the method visibility to public or internal
• Extract the method to another class

Again, if you previously read my other post on non public class and inaccessible constructor you know you should avoid using reflection in tests.

Let's take a look at the other options

Change the method visibility to public or internal

The first thing we should do is to challenge why that method is private in the first place. Why can't we just change its visibility to public or internal (and use the InternalsVisibleTo attribute)?

This breaks encapsulation of the class and will let developers call the method directly in production code. That might not be what you intended to do but can help you in the short term. Abusing this technique will burn you in the long run so be careful with it.

Fortunately, there is a simpler way: extract the method to another class.

Extract the method to another class

If you are lucky, the method you want to extract is static and don't call any other method on the original class. You should be able to extract that method to a static utility class.

But what to do when the method calls other methods and use fields or properties on the class? For that we must analyze the class to extract responsibilities using the Single Responsibility Principle.

Single Responsibility Principle

Can you tell what is the purpose of your class in one sentence without using words like: and, but, also, or, etc.? If not then your class is doing more than one thing. Each segments of the sentence could be in different classes that only have one responsibility each. If the method you want to extract use the same fields than other methods you may want to push them by parameter instead before extraction to the other class.

Find more about the Single Responsibility Principle in an old post of mine.

Unit testing smells: The class constructor is not easy to call

When we want to test an instance method on a class the first challenge is to create an instance of that class. Hopefully the class constructor is easy to call but that's not always the case.

Let's review a few cases where the constructor might prevent us to write tests easily:

• The constructor is private or internal
• It requires too many arguments or it is too hard to create/provide those arguments
• The constructor calls external dependencies

The case of the internal or private constructor

For this we can follow the same advices than with testing non-public class. But whatever you do please don't use reflection to call the constructor.

Also stated in testing non-public class, you should ask yourself if it would be better to test this class via another public class that use it. A private constructor usually means that there is a factory somewhere you should use to instantiate the class. You should figure out a way to use that factory or redesign it in case you have difficulties to work with it in unit tests.

When dealing with internal access modifier I usually use the InternalVisibleTo attribute for my test project.

[assembly: InternalsVisibleTo("Contoso.MyApp.UnitTests.dll")]

The case of the difficult constructor arguments

If the problem is that the constructor requires too many arguments then you should ask yourself if this class is too big, maybe it has too many responsibilities and don't follow the Single Responsibility Principle? In that case the class should be splitted into two or more classes. This way it will be easier to test the smaller class because its constructor should require less arguments.

Another case is when the arguments are difficult to create or provide. Maybe that in order to create one object to pass as parameter we need to create yet more objects. Micheal Feathers calls it the Onion Parameter in his book Working Effectively with Legacy Code. In that case I usually invest into a bit of testing infrastructure like factory methods or Test Data Builder in order to help me write tests faster afterwards.

Finally some parameters could be classes that wrap services or external dependencies. In that case I abstract the dependency using an interface and the Inversion of Control Principle. First extract an interface from the class. Next change the constructor to use this interface instead of the class. Finally use a mocking framework like Moq to create a fake (or create your own by hand if you don't like mocking frameworks) and pass it to the constructor.

public class MyService
{
    // public MyService(SomeDataAccessLayer dal, SomeExternalService externalService)
    public MyService(ISomeDataAccessLayer dal, ISomeExternalService externalService)
    {
        // ...
    }

    // ...
}

The case of the external dependencies calls

When the constructor itself calls an external dependency I usually refactor the constructor to inject this dependency via a parameter instead, this is called dependency injection and usually comes with the Inversion of Control Principle. This is also a good occasion to take a look at a IoC Container like Unity.

public class MyService
{
    // public MyService()
    public MyService(ISomeExternalService externalService)
    {
        // ...
        // var externalService = new ExternalService();
        externalService.CallService();
    }

    // ...
}

Unit test smells: The non-public class

Writing unit tests for a method on a class that is not public is doable but not straight forward. It could be done using a bit of reflection like this

var type = Type.GetType("MyProject.MyClass");
var methodInfo = type.GetMethod("TheMethod");

var classInstance = Activator.CreateInstance(type, null);
methodInfo.Invoke(classInstance, null);

That is quite a bit of work. Of course you could create some test infrastructure to avoid duplication in every tests or you may find libraries online for that. But still, writing tests like this smells funny to me.

In short, you should never write tests directly against a non-public class.
Let's take a look at the 2 possible cases for this: the private class and the internal class.

The case of the private class

For a class to be private means it is nested inside another class

public class A
{
    // ...

    private class B
    {
        // ...
    }
}

In a situation like this class B can only be used by class A. Anything class B do is only for serving class A. If you want to test a method in class B you should find out how class A use class B and write your tests against class A public API.

If you find there is no way to reach the method you want to test in class B through class A it simply means that you just found dead code! If you found a way but find it too hard to setup a test then maybe class B is not simply a private utility class. In that case I would extract class B from inside class A and change its access modifier to internal. Unfortunately, now any class inside the same assembly could use class B. It is a trade-off I'm willing to pay because this case is really rare and C# still lack a proper access modifier scoped to the current namespace.

The case of the internal class

Internal class could also be tested through reflection. Personally I prefer to use the InternalsVisibleToAttribute and give access to internals types to my unit test project. To do it you need to add the attribute to the project under test AssemblyInfo.cs file like this

[assembly: InternalsVisibleTo("Contoso.MyApp.UnitTests.dll")]

If your project is signed you will need to also provide the assembly's public key like this

[assembly: InternalsVisibleTo("Contoso.MyApp.UnitTests.dll, PublicKey=1234...789")]

Again, this is a trade-off: you give special access to your internal types only for testing but it is way better than changing the class access modifier to public. You should never change a type access modifier to public for testing!

Conclusion

I always try to write tests against public classes and methods. Sometime an internal class will grow to be very complex over time and become its own new component. In a solution were we create a lot of small projects we would simply create a new one for such component and expose it publicly but that is not what I do. I usually try to create the minimal number of projects in my solution so testing internal classes using the InternalsVisibleToAttribute is a good trade-off for me.