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.
|
