In a time, where test-driven-development (TDD) is becoming an established way to write a software you naturally write tons of (unit-)testing-code (that’s why it’s called test-driven).

OK, so you define some functionality, which should be exposed by a certain component. So you will most likely have a couple of public methods supporting this functionality. To make sure everything works as expected you write your usual testing-code.

So far so good. So imagine you have a couple of public methods exposing your predefined functionality, and a whole lot of other (private) methods doing some helper-stuff.

During the testing phase you will suddenly find out, some tests are failing. The good developer you are, you have messages associated with your asserts, so will have a clue on why something went wrong. But still, you will have to digg into your code to find, that some helper-methode is all over sudden screwing your whole component.

At this point in time you might want to write tests for those helper methods as well, just to make sure these helpers work expected – just like you do for your public methods. But wait, there is a problem! Usually your unit-tests will reside in a separate assembly, so you will not be able to call those private helper methods at all. But fortunatly there is help on the way … using reflection you can circumvent this problem.

Fortunatly MbUnit has already built in support, for testing such kind of methods using reflection.

Let’s assume you have a class called BusinessClass with a private helper methode DoSomething, which takes a string as a parameter, does some processing and returns some other string. So an appropriate test would be:

using System;
using MbUnit.Framework;
using MbUnit.Framework.Reflection;
[TestFixture]
public class SampleTests
{
[Test]
public void DoSomethingTest()
{
BusinessClass foo = new BusinessClass();
string output = (string)Reflector.InvokeMethod(AccessModifier.NonPublic, foo, "DoSomething", "my input string");
Assert.AreEqual("my output string", output);
}
}