#25 Method Call Requires an Expectation

[Chad M. Gross]

We were previously using v.7.2 that allowed for the
calling of a dynamic mocked interface method without
an expectation attached to it. By looking over the
source, it looks like since v .7.5 this is no longer
possible. In the current version, v.7.6, the Call method
receives an IMethodCallExpectation from the
nextExpectation method. This method will return null if
there are no expectations and you are not strict. The
Call method is not handling null being returned and
therefore you get the NullReferenceException. In the
v.7.2 implementation, the code would have been:

IMethodCallExpectation e = nextExpectation
(methodCall);
if (e == null)
return null;

return e.CheckCallAndSendResponse(methodCall);

Here is a test that fails in the current version:

public interface ITest
{
void MethodTest();
}

[TestFixture]
public class TestDynamicMock
{
[Test]
public void
TestDynamicMockMethodWithoutExpectations()
{
DynamicMock dynamicMock =
new DynamicMock(typeof(ITest));

    ITest test = \(ITest\)

dynamicMock.Object;
test.MethodTest();
}
}

[Choy Rim]

Logged In: YES
user_id=1023300

Here I thought I was correcting a bug. All the unit tests
passed.

Personally I feel that this old *feature* was a bug. But
that's my narrow viewpoint. We should open this up to argue
the good and the bad.

Maybe Griffin or some of the other users can shed some light
as to why this is not a bug.

If the test didn't have to specify the expectation, then it
wouldn't clearly document the interaction between two
objects. would this be useful for method calls that are
irrelevant to the test?

[Choy Rim]

Logged In: YES
user_id=1023300

Well, it doesnt look like anyone is interested in discussing
this. And when in doubt, support backward compatibility.
I'll go back and change this when I get a chance.

It'll be a while though. My computer crashed and I've been
having trouble restoring it.

[Arild Fines]

Logged In: YES
user_id=676362

> Here I thought I was correcting a bug.

How can it be considered "correcting a bug" when you
introduce a NullReferenceException that comes out of nowhere
with no relevant information as to what went wrong?

> If the test didn't have to specify the expectation, then
it
>wouldn't clearly document the interaction between two
objects.

That's what the .Strict property is for. This bug (and yes,
it's most definitely a bug) is in violation of the
documentation for the Strict property.

Fortunately I can fix this for myself, or I'd have no choice
but to abandon the use of DotNetMock altogether. This
behavior is quite clearly unacceptable.

[Choy Rim]

Logged In: YES
user_id=1023300

Yeah it should do what it used to do. I'll fix it. Looks
like you've already included a solution.