Re: [Mockobjects-java-dev] Advantage for In-Container vs Mock ?

[Thomas C. <ald...@ne...>]

Steve

Thank you for your feedback.

"why would you assert the verify? The verify method should throw an
AssertionFailedException if it fails."

Agreed.

"why don't you use an ExpectationCounter? Also, how does the check method
differ from using Verifiable, which is a consistent interface we use across
the library (and is searcheable by reflection)."

Sure, let's use the ExpectationCounter with the inc() and verify() methods.
I used CallCounter simply to show that the goal for the check() method is
not to do any verification of parameters used in method calls or of  return
values, but simply to check that the *number* of method calls is correct.
Most of the verification of correct parameters and such is done in the
overridden methods themselves.

As long as the references in the outer class are final, we can use any of
the Expectation-implementing classes of com.mockobjects.* *anywhere* in the
test, including in the anonymous inner class methods, and call their verify
methods at the end of test as appropriate. So far, through refactoring and
demeter-based method design of the production classes, my experience is that
the simple counter suffices. Do you have any complex class examples where
doing verifications in the inner class and checking the number of method
calls via a counter is not adequate?

"Are you saying that the trick is to implement in the inner class only those
methods you need for the current test? If so, that need clarifying."

This is precisely the point. We only override the methods we need for the
current test and make our assertions within those overridden methods. We can
also, as above, use an ExpectationCounter to check message calls. If this is
not clear, what do you suggest to make sure it is clear?

Also, remember that the current context is pre-JDK 1.3 *with* interfaces to
mock. If we use JDK 1.3, we use a proxy and declare an invocation handler as
an anonymous class - we do not need to provide *any* mock implementation
class and only have to implement handling for the specific methods used by
the method being tested.

Putting JDK 1.3 aside, the mock objects project, AFAIK, is dependent on the
existence of interfaces for everything that is mocked. IMO, this is an
unrealistic expectation of a project where it is not generally useful to
have an interface for every single class, especially package protected
classes. Therefore, there are some classes for which we want to mock a
subset of their methods for a particular test, but have no interface. The
inner class patterns allow the overriding to facilitate this. Moreover, when
testing a method of a particular class, we can use an anonymous inner class
to override other methods of the *same class* as necessary to make
fine-grained assertions and test our expectations. How do we do this
without the patterns described?

Tom