using (RecordExpectations r = new RecordExpectations())
{
r.ExpectAndReturn(
MyComplexFactory.GetSomeObject().Manager.DoSomething("a"),
false);
}
The chaining code above is cool. That's the very first thing I've seen out of TypeMock that looks like an advantage over Rhino for me.
Although, I'll still dissent. That's a Law of Demeter violation that might be leading poor encapsulation and all the problems that that brings. Just because you can, doesn't mean you should.
Jeremy: not if you're talking about a fluent interface that you're building.
Roy: Actually, it's even more painful with a fluent interface, but that has nothing to do with mock objects at all.
You wouldn't want to test an FI with mock objects. From painful experience, unit testing a fluent interface works best when you're doing a state based test on the outcome. I quit trying to "unit test" the individual expressions. test the results and not the intermediary stuff because the FI expressions go through a lot of churn along the way.
Otherwise you're just going to fall into the overspecification trap.
Jeremy: I agree that testing the individual parts of a fluent interface sucks. but with "pure' tdd without using Rhinomocks you're forced either do aan intergration test (state based) which could be painful if the interface does funky stuff with dependencies underneath) or you have to stub out some of the objects in the chain.
My point was that you can create a fluent interface in a TDD fashion by simply expecting on it in a recorder scope and actually using it underneath.
Also, you can create code that USES a FI using TDD by allowing the code you write to use the actual FI which is stubbed out.