[MO-java-dev] DynaMock proxy toString issue

[chris c. <drc...@ya...>]

Hi all,
	there's a bug/limitation in the DynamicUtil.proxyToString method that I'd 
like to fix. It can't handle proxies in collections or where the toString 
is called indirectly because the proxy is a field in some other class. The 
reason this is irritating is that the DynamicUtil.proxyToString method is 
used in displaying constraints when call has not been matched. The result 
of this limitation is that if you have an unexpected call and some other 
call has proxies in the constraints indirectly then the failure message is 
masked by an unexpected call to toString.
 a code snippet might make this clearer:
...
Action proxyAction1 = (Action) mockAction1.proxy();
Action proxyAction2 = (Action) mockAction2.proxy();
Collection listOfActions = new TestVector(proxyAction1, proxyAction2);

 mockConfigVersion.expectAndReturn("applyToSubConfigs", 
C.eq(versionRepository, listOfActions), true);
...

The DynamicUtil.proxyToString will not be able to display the listOfActions 
properly so any failed expectation on mockConfigVersion will be hidden by 
an unexpected call to "toString" on mockAction1. Lots of time will then be 
spent stepping
through the code to find which call went wrong.  This has happened to me 
often enough to be a nuisance.

The solution I propose is to not use the DynamicUtil to handle the toString 
and instead make the default behaviour of a proxy toString call to be to 
return the name of the mock. This would be overriden if an expectation was 
set on the toString or you could use the reset method to clear it. The 
reason I think it should be done this way is that I can't see how the 
DynamicUtil can be made to handle all the possible ways that the toString 
might be called on the proxy. Also I think it is unusual to need to set an 
expectation on toString (I have never done it other than to get around this 
bug) but less unusual to use proxies inside other objects which are used in 
constraints. The way I had thought of implementing this behaviour is to add 
a match of toString into the callableAddable of the Mock on construction.

Any thoughts?
Chris