AutoMockingUnityContainer and Rhino Mock

I've been putting a lot of time into understanding TDD and Mocking the last few weeks. Combine that with Unity, and it's a lot of stuff to get a grip on.

I've been going with Rhino Mock as my mocking framework, and it seems to work okay as long as you are developing new code. If I were working on legacy code, I think it's pretty clear you would want to use TypeMock Isolator. You could justify the expense pretty quickly.

I was trying to use Roy Osherove's AutoMockingUnityContainer to make my test fixtures perfect, since I am setting up the model for all the other devs to follow. Roy published this back in April 2008, and since then, Rhino Mock has released a new version that makes use of lambda expressions to eliminate the need to do the mocks.Record step. Instead, you should be able to do the following:


ILogger logger = container.Resolve();
logger.Stub(x => x.IsLogFileFull()).Returns(true);


I say should, because this is what I understand. I may have misunderstood.

This should force the IsLogFileFull to always return true when called in the example Roy shows. But for some reason, it always returns false for me. I went through a hundred iterations of code, and ended up going back to the original syntax, which isn't quite as clear, but works.

I will say that my "Logger" class is not passed into the constructor but is set as a property after the class is resolved. Maybe that is the issue, but I am testing a very high level function, and it calls a number of different classes that I want to mock / stub, and I would hate to have a class that has five or six arguments required in the constructor (even if it is just for testing sake). The class is wired up to Unity itself so I normally don't need to pass these in, just when I want to mock.

Maybe that is a reason in itself to go to TypeMock, but I need to prove to my folks here that TDD and Mocking is going to pay off at all, before I try to prove that we need to spend more money to do it.