TypeMock too powerful to use

In my early stages of following TDD light I was looking for a mock object framework. I tried Rhino.Mocks and found it hard to use. Then I tried TypeMock and falled in love with the product. It allows mocking almost anything. With TypeMock I only failed to mock SqlDataReader because it doesn’t have a public constructor.

It was then. Today I believe that TypeMock is bad for the same reason I loved it before. It’s too powerful. It doesn’t force you to write a testable code.

The reason I found Rhino.Mocks hard to use is because I haven’t learn yet about Inversion of Control Containers and the Dependency Injection pattern. Today I write my own mock objects without using any framework. However, if you want to use a Mock Framework, I strongly recommend Rhino.Mocks.

If you’re not familiar with this pattern I recommend to read Jeremy Palermo’s article Simple dependency injection to get you started with unit testing.

Testing Non-Public members with MbUnit

MbUnit Test Framework allows you to test non-public members of a class. You can test private, protected, internal, and of course protected internal members. Members can be fields, properties, and methods.

Let’s create MyClass with non-public members:


public class MyClass
{
  private string _field = "Private";

  private string PrivateProperty
  {
    get { return _field; }
  }

  private string GetHello()
  {
    return "Hello";
  }

  private int PrivateAdd(int x, int y)
  {
    return x + y;
  }

  protected double PrivateAdd(double x, double y)
  {
    return x + y;
  }
}



As you can see we have one private field, one private property, two private methods, and one protected. Two PrivateAdd methods were created to show that you can test overloaded methods.

First, let’s create MyClassTests class that will test MyClass. In order to use MbUnit Framework, we need to add reference to MbUnit.Framework.dll.
Also we need to add reference to MbUnit.Framework.2.0.dll. The later one has Reflector class that we’re going to use to test private and protected members.

We have a choice of using static methods of Reflector class or create an instance of Reflector. I’m personally not a big fan of static methods. Currently using static methods you can test only non-public fields and methods without arguments. If some people would like to be able to test properties and methods with arguments using static methods, just let MbUnit community know and the will be happy to add it for you.
One more thing: if a name of a member incorrect, an exception is thrown with a similar message:

Fail to find NoExisit Method in MyClass.MyClass.

Well, enough talking here’s the fixture:


[TestFixture]
public class MyClassTests
{
  Reflector _reflector;

  [TestFixtureSetUp]
  public void FixtureInit()
  {
    MyClass myClass = new MyClass();
    _reflector = new Reflector(myClass);
  }

  [Test]
  public void PrivateField_Test()
  {
    Assert.AreEqual("Private"
      ,_reflector.GetNonPublicField("_field"));
  }

  [Test]
  public void Static_PrivateField_Test()
  {
    Assert.AreEqual("Private"
      , Reflector.GetNonPublicVariable(new MyClass(), "_field"));
  }
  
  [Test]
  public void PrivateProperty_Test()
  {
    Assert.AreEqual("Private"
      , _reflector.GetNonPublicProperty("PrivateProperty"));
  }

  [Test]
  public void PrivateMethodNoArguments_Test()
  {
    Assert.AreEqual("Hello"
      , _reflector.RunPrivateMethod("GetHello"));
  }

  [Test]
  public void Static_PrivateMethodNoArguments_Test()
  {
    Assert.AreEqual("Hello"
      , Reflector.RunNonPublicMethod(new MyClass(), "GetHello"));
  }

  [Test]
  public void PrivateMethod_Test()
  {
    Assert.AreEqual(5
      , _reflector.RunPrivateMethod("PrivateAdd", 2, 3));
  }

  [Test]
  public void ProtectedMethod_Test()
  {
    Assert.AreEqual(5.6
      , _reflector.RunPrivateMethod("PrivateAdd", 3.5, 2.1));
  }

  [Test]
  [ExpectedException(typeof(ApplicationException))]
  public void NonExstingMethod_Test()
  {
     _reflector.RunPrivateMethod("NoExisit");
  }
}