Where it led me was to re-investigate Partial Mocks in Rhino Mocks.  My original misunderstanding of Partial Mocks was that they would only mock Abstract Classes.  A partial mock will mock ANY class -- but only the Partial mock will only mock abstract methods.  That small misunderstanding has caused me to loose untold amount of hair and good will towards all men.

So I'm going to re-implement my class methods.  Here you go:

public class MyClass
{
    public int Foo()
    {
        // stuff happens here
        int i = Bar();
        // do more stuff here    
        return i + 5;
    }
    public virtual int Bar()
    {
       // do some logic
       return 1;
    }
}

A few changes here.  First, I removed the delegate and renamed BarInternal back to Bar.  Second, I marked the Bar method as virtual. 

They key point about a virtual method is that you can provide an implementation, and then a inherited class can completely override that method.  That is what the Partial Mock is allowing us to do.

So how do I write my tests?  If you don't like using Rhino Mocks you do this:

[Test]
public void FooTest()
{
    int expected = 7;
    int result = 0;
    MockRepository mock = new MockRepository();
    MyClass c = mock.PartialMock<MyClass>();

    using (mock.Record())
    {
        Expect.Call(c.Bar()).Return(2);
    }
    using (mock.Playback())
    {
        result = c.Foo();
    }

    Assert.AreEqual(expected, result);
}

Obviously, now my test is referencing the Rhino Mocks library.  The variable mock is the Mock Repository.  Now the big change is that I don't create MyClass directly, but through the Rhino Mocks PartialMock method.

Next, I tell the mock repository to expect a call to c.Bar, and when called return 2.  That is what is happening in the using (mock.Record()) section of the code.  Then, in the mock.Playback section, I call Foo().

One other quick note, if we were to rewrite Foo such that it no longer called Bar this test will fail.  The Expect.Call part tell the mock repository that the method Bar will be called, and if it isn't there is a problem.  There are ways around that as well, but that is a topic for another day.

Where does that leave us now?  Aside from the odd "virtual" keyword thrown into our production code, this is the code as you would have originally written it, even without TDD.  I don't like making API changes just to satisfy testing, but I am very OK with this change.

But what about that new kid on the block?  You know, Moq.

I still love Rhino Mocks, but I can't help but want to play with a new toy.  So here is the same thing, but in Moq:

[Test]
public void Foo_moq_test()
{
    Mock<MyClass> mock = new Mock<MyClass>();
    mock.Expect(x => x.Bar()).Returns(2);

    MyClass c = mock.Object;
    int result = c.Foo();
    Assert.AreEqual(7, result);
}

So as you should be able to see, Moq is a very different animal than RhinoMocks.  There is no Record or Playback (the web site calls those confusing, I disagree, but still), and the Expect happens with a anonymous delegate (in the form of the Lambda Expression "x => x.Bar()" where x is of type MyClass).

The cool part is that you can get the same results with less code using Moq.  That has been the main advantage all along.  My informal testing also reveals that Moq is just a hair faster than Rhino Mocks (but not fast enough to warrant switching frameworks).

The problem

You have two methods (Foo and Bar), and Foo calls method Bar.  It will look like this:

public int Foo()
{
    // stuff happens here
    int i = Bar();
    // do more stuff here
    return i + 5
}

public int Bar()
{
   // do some logic
   return 1;
}

Now you need to test both methods.  Bar can be easily tested like this (this should work for NUnit and MBUnit tests -- assuming both methods exist in a class call MyClass):

[Test]
public void Bar_Test()
{
    MyClass c = new MyClass();
   int result = c.Bar();
   Assert.AreEqual(1, result);
}

Now we test Foo:

[Test]
public void Foo_Test()
{
   MyClass c = new MyClass();
   int result = c.Foo();
   Assert.AreEqual(6, result);
}

Here is where we have an issue.  What if the result of Bar changes?  That will break the test.  So now we have a brittle test.  Any time Bar changes, we have to change all of the Bar tests, but also the Foo tests, so we have added complexity to our tests as well.  Now if Foo (or Bar) was in a separate class, this wouldn't be an issue, but they are in the same class.  And as much as I like small classes, this seems too trivial to split up (even in the context of an extremely trivial example).

The Solution

What I would like to do is Mock the method Bar.  You can do that with a delegate.

Without really getting into what a delegate is, I will just show the code.  So here are my two methods, with a delegate added in for good measure.

public delegate int BarDelegate();

public BarDelegate Bar;

public MyClass()
{
    Bar = BarInternal;
}

public int Foo()
{
    // stuff happens here
    int i = Bar();
    // do more stuff here    
    return i + 5;
}

public int BarInternal()
{
   // do some logic
   return 1;
}

OK, here is what I did:

1. Renamed Bar to BarInternal
2. BarDelegate delegate
3. Created a variable named Bar to point to the method BarInternal
4. Created a constructor to hook up Bar to BarInternal.

Now all of my code can still use the method Bar just like it was there, but in actuality it is calling BarInternal.  I have now created one layer of indirection to my method Bar so it can now be mocked and tested.

Here is my new test for Foo:

[Test]
public void FooTest()
{
    MyClass c = new MyClass()
    c.Bar = BarMethodForTest;
    int result = target.Foo();
    Assert.AreEqual(7, result);
}

private int BarMethodForTest()
{
    return 2;
}

So what is new with the test is the BarMethodForTest that is passed to c.Bar and I have coded BarMethodForTest to always return 2.  When I set c.Bar to my new method, BarInternal (the default method) is no longer called.

Actually, if I wanted to I could simplify this further by setting c.Bar with an anonymous delegate like this:

[Test]
public void FooTest()
{
    MyClass c = new MyClass()
    c.Bar = delegate() { return 2; }
    int result = target.Foo();
    Assert.AreEqual(7, result);
}

Stepping Back

OK, take a step back and look at this again with a critical eye.  Have I really solved the problem?   Yes and no.  The real problem was that my methods were too complex to simply test.  Now my methods are simple to test, but the code is complex to read.  All I've done is shifted the complexity from one class to the other.  A better solution would to have created another class and further abstracted out the logic.

At the same time, my class is not overly burdened by the change either.  In lieu of a real refactoring, I do consider this a viable solution to the problem.  So by all means do this -- but make sure you are out of alternatives first.

The problem

You have two methods (Foo and Bar), and Foo calls method Bar.  It will look like this:

public int Foo()
{
    // stuff happens here
    int i = Bar();
    // do more stuff here
    return i + 5
}

public int Bar()
{
   // do some logic
   return 1;
}

Now you need to test both methods.  Bar can be easily tested like this (this should work for NUnit and MBUnit tests -- assuming both methods exist in a class call MyClass):

[Test]
public void Bar_Test()
{
    MyClass c = new MyClass();
   int result = c.Bar();
   Assert.AreEqual(1, result);
}

Now we test Foo:

[Test]
public void Foo_Test()
{
   MyClass c = new MyClass();
   int result = c.Foo();
   Assert.AreEqual(6, result);
}

Here is where we have an issue.  What if the result of Bar changes?  That will break the test.  So now we have a brittle test.  Any time Bar changes, we have to change all of the Bar tests, but also the Foo tests, so we have added complexity to our tests as well.  Now if Foo (or Bar) was in a separate class, this wouldn't be an issue, but they are in the same class.  And as much as I like small classes, this seems too trivial to split up (even in the context of an extremely trivial example).

The Solution

What I would like to do is Mock the method Bar.  You can do that with a delegate.

Without really getting into what a delegate is, I will just show the code.  So here are my two methods, with a delegate added in for good measure.

public delegate int BarDelegate();

public BarDelegate Bar;

public MyClass()
{
    Bar = BarInternal;
}

public int Foo()
{
    // stuff happens here
    int i = Bar();
    // do more stuff here    
    return i + 5;
}

public int BarInternal()
{
   // do some logic
   return 1;
}

OK, here is what I did:

1. Renamed Bar to BarInternal
2. BarDelegate delegate
3. Created a variable named Bar to point to the method BarInternal
4. Created a constructor to hook up Bar to BarInternal.

Now all of my code can still use the method Bar just like it was there, but in actuality it is calling BarInternal.  I have now created one layer of indirection to my method Bar so it can now be mocked and tested.

Here is my new test for Foo:

[Test]
public void FooTest()
{
    MyClass c = new MyClass()
    c.Bar = BarMethodForTest;
    int result = target.Foo();
    Assert.AreEqual(7, result);
}

private int BarMethodForTest()
{
    return 2;
}

So what is new with the test is the BarMethodForTest that is passed to c.Bar and I have coded BarMethodForTest to always return 2.  When I set c.Bar to my new method, BarInternal (the default method) is no longer called.

Actually, if I wanted to I could simplify this further by setting c.Bar with an anonymous delegate like this:

[Test]
public void FooTest()
{
    MyClass c = new MyClass()
    c.Bar = delegate() { return 2; }
    int result = target.Foo();
    Assert.AreEqual(7, result);
}

Stepping Back

OK, take a step back and look at this again with a critical eye.  Have I really solved the problem?   Yes and no.  The real problem was that my methods were too complex to simply test.  Now my methods are simple to test, but the code is complex to read.  All I've done is shifted the complexity from one class to the other.  A better solution would to have created another class and further abstracted out the logic.

At the same time, my class is not overly burdened by the change either.  In lieu of a real refactoring, I do consider this a viable solution to the problem.  So by all means do this -- but make sure you are out of alternatives first.