|
From: Nat P. <nat...@gm...> - 2008-01-24 18:16:11
|
On 23/01/2008, Steve Mitcham <Ste...@ty...> wrote:
> I've looked a jMock's implementation and I've looked at Rhino. I don't
> really like the two line setups with the Call/LastCall that is the same as
> the Rhino expectations. I'm trying to think of an 'NMock-like'
> implementation of the same thing that keeps the fluent interface going.
JMock's API was a desperate attempt to work around Java's butt-ugly
syntax for closures. C# has a cleaner syntax, so you could do
something like the example below.
A mockA = mockery.mock(typeof(A));
B mockB = mockery.mock(typeof(B));
mockery.Checking(delegate {
mockA.DoSomething(EqualTo(B), NotNull);
Once; mockB.GetStuff(); Will(Return("stuff"));
});
The Checking method would put the mockery into a "record" state, call
the delegate, and then put the mockery back into a "check" state.
That would be much easier to implement in C# than Java because C# has
real generics and closures.
Even better would be something like:
mockery.Checking(delegate {
... run the test in here
}.WillCause(delegate {
... expectations in here
});
Which makes the expectations read more like assertions. It puts the
tested code and the expectations in causal order, which is easier to
read I think.
--Nat
|