How to Test Private and Protected methods in .NET

• Download demo project - 23.8 Kb

Introduction

Test Driven Development is the practice of (1) writing tests, (2) writing code that passes those tests, and (3) then refactoring. This concept is becoming very popular in the .NET community due to the quality assurance that it adds. While it is easy to test public methods, the natural question emerges "How do I test protected and private methods?"

This article will:

• Summarize some key points of the "Should-you-even-test private methods debate"?
• Make the case that it is still useful to at least know how to test private and protected methods - regardless of which side of the debate you're on.
• Provide the theory and downloadable code sample to demonstrate these testing techniques.

Background Theory

Should You Test Private Methods?

A Google search will show you that there's a lot of debate about using private methods, let alone testing them. The table below summarizes some of the common views of the pro and con for both issues.

There are bright and experienced people on both sides of the issue. So while I have no intention or expectation of ending the "should I test private method" debate, there is still value for both sides to know how to test them. Even if you think that private methods should not be tested:

• Your opinion will be more influential if you can at least show that you are able to test them, but choose not to (i.e. you're not saying "Don't test private methods" simply because you don't know how).
• Having the option of testing non-public methods lets you see what really works best for your team over time.
• As long as there are still some valid situations, it's worth having a convenient way to test them.

Good Criteria and Inadequate Techniques

Andrew Hunt and David Thomas explain in their book, Pragmatic Unit Testing in C# with NUnit, that good unit tests are ATRIP:

• Automatic
• Thorough
• Repeatable
• Independent
• Professional

There are three additional criteria that any testing overhead for private/protected methods should meet:

• Transparency - Don't alter the System Under Test (SUT), such as adding wrapper methods in the production code.
• Scope - Be able to run in both Debug and Release mode.
• Simplicity - Have minimal overhead, and hence be easy to change and simple enough to introduce minimal risk.

Keeping these criteria in mind, there are several strategies that fall short:

Testing Protected Methods

A protected method is visible only to derived classes, therefore it is not immediately available to a test suite. For example, suppose we wanted to test the method from ClassLibrary1.MyObject:

protected string MyProtectedMethod(string strInput, int i32Value) 
{
    return this.Name + ": " + strInput + ", " + 
     i32Value.ToString();
}

The book Pragmatic Unit Testing in C# with NUnit explains one solution: make a derived class MyObjectTester that inherits class MyObject, and then create a public method TestMyProtectedMethod that wraps the protected one. For example:

public new string TestMyProtectedMethod(string strInput, int i32Value) 
{
    return base.MyProtectedMethod(strInput, 
     i32Value);
}

This approach is simple, yet meets all the criteria:

Testing Private Methods

Testing private methods is a little more involved; but we can still do it using System.Reflection. You can use Reflection to dynamically access methods of a type, including both instance and static private methods. Note that accessing private methods does require the ReflectionPermission, but that is not a problem for Unit Tests running on a development machine or build server.

Suppose we wanted to test the private method MyPrivateMethod from ClassLibrary1.MyObject:

private string MyPrivateMethod(string strInput, DateTime dt, double 
 dbl) 
{
    return this.Name + ": " + strInput + ", " + 
     dt.ToString() + ", " + dbl.ToString();
}

One solution is to create a UnitTestUtilities project with a helper class to call the test method via reflection. For example, the download solution has the following methods in UnitTestUtilities.Helper:

public static object RunStaticMethod(System.Type t, string strMethod, 
 object [] aobjParams) 
{
    BindingFlags eFlags = 
     BindingFlags.Static | BindingFlags.Public | 
     BindingFlags.NonPublic;
    return RunMethod(t, strMethod, 
     null, aobjParams, eFlags);
} //end of method

public static object RunInstanceMethod(System.Type t, string strMethod, 
 object objInstance, object [] aobjParams) 
{
    BindingFlags eFlags = BindingFlags.Instance | BindingFlags.Public | 
     BindingFlags.NonPublic;
    return RunMethod(t, strMethod, 
     objInstance, aobjParams, eFlags);
} //end of method

private static object RunMethod(System.Type t, string 
 strMethod, object objInstance, object [] aobjParams, BindingFlags eFlags) 
{
    MethodInfo m;
    try 
    {
        m = t.GetMethod(strMethod, eFlags);
        if (m == null)
        {
             throw new ArgumentException("There is no method '" + 
              strMethod + "' for type '" + t.ToString() + "'.");
        }
                                
        object objRet = m.Invoke(objInstance, aobjParams);
        return objRet;
    }
    catch
    {
        throw;
    }
} //end of method

Private method RunMethod takes in the necessary parameters that Reflection needs to invoke a method, and then returns the value. It has two public methods that wrap this: RunStaticMethod and RunInstanceMethod for static and instance methods respectively.

Walking through RunMethod, it first gets the

MethodInfo 

We could use this Utility in an NUnit test like so:

[Test] public void TestPrivateInstanceMethod()
{
    string strExpected = "MyName: Hello, 5/24/2004 
     12:00:00 AM, 2.1";
     
    ClassLibrary1.MyObject objInstance 
     = new MyObject("MyName");
    
    object obj = 
     UnitTestUtilities.Helper.RunInstanceMethod(
     typeof(ClassLibrary1.MyObject), "MyPrivateMethod",
     objInstance, new object[3] {"Hello", 
     new DateTime(2004,05,24), 2.1});
    
    string strActual = Convert.ToString(obj);
    
    Assert.AreEqual(strExpected,strActual);
}

Conclusion

While there is a debate on whether or not to test private methods, at least we have the ability to do so. We can test protected methods using inheritance to create a derived TesterClass that wraps the base protected methods with public ones. We can test private methods using Reflection, which can be abstracted to a UnitTestUtility helper class. Both of these techniques can help to improve test coverage.