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.