#4 Validation of Mock.expect*(..) arguments

[Barry Kaplan]

A very common error in test setup is to define
expectations for which there never will be match. For
example, given:

public interface Foo {
public void bar(Blob blob);
}
...
// 1. no method tweetle on interface
mockFoo.expect("tweetle", aBlob);
// 2. no bar method that takes two arguments
mockFoo.expect("bar", C.args(C.eq(aBlob), C.eq(aTweetle)));
// 3. no bar method that returns a Tweetle
mockFoo.expectAndReturn("bar", aBlob, aTweetle);
// 4. no bar method that takes a Tweetle argument
mockFoo.expect("bar", C.eq(aTweetle));

1, 2, 3 /could/ be done with the current design. It
just isnt' resulting strange test executions that
could have failed immediatly at setup time.

4 would require some method of "knowing" a constraint's
type. That is the type of its argument. Of course this
may not always be possible, but when it is could be
used to help validate the expectations.

---

Comment from Nat on this subject:

Request 4 is impossible for most constraints (because a
Constraint has no concept of "type") unless we extend
the Constraint interface with methods that to perform
early checks. However, I would rather keep the
Constraint interface as simple as possible to make it
trivially easy to write new Constraints. That approach
has helped make the
Constraint concept very easy for new users to
understand and use, and also kept the Constraint
interface very stable (it hasn't changed since first
introduced).