Re: [MO-java-dev] Java Dynamic Mocks - going to Head?

[Steve F. <st...@m3...>]

About time someone had the time to finish up the library!

Here's some things I think we ought to do:

- announce on MO-java-users, I have no idea whether anyone out there is
using this stuff.

- it would be really, really nice if someone would volunteer to help
clean up the build. It's lotsa fun to write new features, but there's
some boring stuff to do as well. In particular, we need to split out the
website and maybe move to the Wiki that Joe's so kindly set up.

- there's also a noticeable amount of duplication in the code. Who will 
take responsibility for tidying it up after the initial commit?

- Jeff, I'd like to pull the alt code out as a separate library. What do
you think?

Tim Mackinnon wrote:
> Anyway - the library is working out quite well now and we should consider
> rolling it in to the head stream soom! (Maybe a day or two more of "in
> usage" testing, and comments from anyone else who is interested - but to be
> honest making it available in the head should allow greater changes).
> 
> Here are some points:
> 
> 1) To test the dynamic stuff, we used Traditional Mocks - it became a pain
> hand coding them, especially on larger interfaces, so we took the decision
> to use MockMaker. This worked well, however their are some ReturnXXX objects
> [...]

How about moving the mockmaker stuff into a holding package, or at least 
commenting it? Right now it's confusing and there are no cues for what 
to use.

> 2) The Callable interface has a "matches" method, this doesn't feel right
> for all callables, its required for CallBag to operate - others don't need
> it. This should be removed and implemented as a private decoration for
> CallBag.

How else can we tell if an incorrect method call has been made? I 
thought that was part of what matches did?

> 4) As you can use mocks as expected values themselves - there was some
> ugliness with the proxies needing to detect equality of mocks (you can see
> this in the invoke method). I'm not sure if there is a better way to do
> this.

Can we have an example of how this is used? Also, what's this 
"getMockName" thing?

> 5) I think Mocks should probably register with something so that we can do
> the Verifier.verify on both instance variables and local variables in a
> test. I am still seeing lots of accidently unverified mocks

you mean (gasp) a global collection? Is this a problem because of the 
structure of your tests?

S.

-- 
"A LISP programmer knows the value of everything but the cost of nothing.
  A C programmer knows the cost of everything but the value of nothing."
(Todd Proebsting)