Re: [MO-java-dev] dynamic mock cannot handle overloaded methods

[Nat P. <nat...@b1...>]

Instead of discussing how to *implement* overloaded mocked methods, lets
work out how tests will specify overloaded mocked methods, and go from
there.

What do you think of my API suggestion?

Cheers,
	Nat.

On Tue, 2002-11-19 at 16:43, Barry Kaplan wrote:
> >
> >
> >I'm confused about this:  
> >
> >* MockCall *is* part of the public interface.
> >
> Adding a method to MockCall will not break existing code. (But it will 
> make creating anonymous inners harder, as you point out below.)

It will break all code that defines classes that implement MockCall.

The MockCall interface is part of the Mock API, because of the methods
setup(name,MockCall) and expect(name,MockCall).


> >* Constraints do not specify the expected argument types, so I don't see
> >how querying for a list of constraints will help you overload on
> >argument types.
> >
> Not the constraints, but the Class of the object being constrained.

The Constraints do not have any knowledge of the class of the object
being constraint, except for the IsInstanceOf constraint, which is a
special case.

> >* MockCall objects do not have to have Constraints -- they can check
> >argument values in any way they choose.  For example, I have tests that
> >uses anonymous inner classes that implement MockCall and call JUnit
> >assertions in the call method.
> >
> Good point. Since it is MethodMap that really needs the overload 
> support, method map could determine the concrete method by asking 
> Constraint for the constrained Class in expectCall/setupCall. But how to 
> handle MethodMap.setupCall(String methodName, MockCall call)?
> 
> >
> >* The MockCall method is very simple so that it is easy to create
> >anonymous inner classes that implement from MockCall.  I don't want to
> >add any additional methods to the MockCall interface to keep this
> >simplicity.
> >
> Yes, what I was thinking of would make doing so a bit harder. Maybe a 
> more generic AbstractMockCall could aleviate this.
> 
> >
> >* Why do you want to add a method to query the state of a MockCall? 
> >What does the caller of this method do with the queried information? 
> >And why can the MockCall not do this?  (Law of Demeter/Tell Don't Ask).
> >
> MockCall does not know the method name, let alone the class on which 
> method is declared. So for MockCall to be able to return the Method [for 
> use as a key in the MethodMap] it would need to be constructed with the 
> object or class that is being mocked. Then MethodMap could delegated to 
> MockCall to get the Method. (Maybe MockCall's hash function could return 
> method so MockCall does not need to expose Method at all.)
> 
> What explicity were you thinking of "telling" MockCall? To register 
> itself in the MethodMap as unique Method?
> 
> >I would like to see what the API would be like and how it would be used
> >before making such drastc changes.  From that we can work towards the
> >design of the interna
> >
> Of course. I'm sure there lots of issues that I have not yet considered. 
> (I only started looking at the dynamic mocks a couple of days ago.) I'll 
> knock out a spike, hopefully this weekend, and post it for discussion. I 
> also need to convert a lot more of our tests to use the dynamic mocks 
> before I am confident of handling the forces.
> 
> -bk
-- 
Nat Pryce <nat...@b1...>
B13media