Re: [MO-java-dev] Why doesn't Mock check method parameter types as well as method names?

[Barry K. <bk...@in...>]

Tim Mackinnon wrote:

> Can you give a concrete example?
> 
> If you set the wrong expectations then I would expect a failure???

Sure:

public interface Foo {
     public void bar(Blob b, Goo g);
}

public void testFoo() {
     Blob expectedBlob = ...
     Mock mockFoo = new Mock();
     mockFoo.expectVoid("bar", new Constrant[]{C.eq(expectedBlob)});
         // The expectation is incorrect: There is no method "bar"
         // that takes just the Blob parameter. It would be nice if
         // the test failed immediatly at this point and indicated
         // a test setup error.

     SomethingThatUsesFoo s = new SomethingThatUsesFoo();
     s.useFoo(mockFoo);

     mockFoo.verify();
         // This verify will indeed fail, but it states that
         // "bar(Blob b)" did not get called. While this is true
         // it is misleading, as there is no such method, and
         // could never be called.
}


Does that make sense?

If the creation of the expectation checked that a method with the 
appropriate parameter types existed, then the test would fail much 
sooner, and provide much more direct feedback as to why the test failed. 
In addition, the error message would clearly indicated that  the problem 
is an issue of test setup not program correctness; maybe a simple 
mistake, or maybe a result of a refactoring.

For expect*() to be able to lookup the method, it would need to know the 
types of the parameters. But what it currently gets is Constraint's. 
Maybe Constraint could have a method such as getType() or 
getConstrainedClass(), which it obtains from the constructor argument. 
The IS_ANY would need to take a class argument I would think to make 
this work.

I brought this issue up a while ago on this list, but it was not really 
well received, or more likely I poorly described the issue. I suppose 
for smallish systems, these types of errors would not be too much 
trouble to fix after the test fails. But when you have 6000+ tests, a 
method refactoring on high-abstract/high-dependent class that 
invalidates mock setups could break hundreds of tests.

This was on of the benefits of EasyMock -- it used the actual typed 
interface for setting up expectations. But at the huge cost of no 
Constraints. I would prefer compile-time failure when expectations 
reference a non-existant method, but see no way to do that other then 
with some type of introspection on the class files.