Re: [MO-java-dev] InterfaceImplementor

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

For those of us (unlike Jeff) using an IDE, aligning class with
interfaces is pretty easy.

What I find more interesting is the idea of using dynamic proxies to
catch the unimplemented methods (like Smalltalk doesNotUnderstand),
rather than the EasyMock approach of using a dynamic proxy to record and
playback the behaviour. You could then use local overrides to implement
the behaviour for a given test. Now Jeff has split the jdk's it might be
worth investigating this for versions 1.3+

Steve

----- Original Message -----
From: "Jeff Martin" <je...@mk...>
To: "MockObjects" <moc...@li...>
Sent: Wednesday, April 17, 2002 1:53 PM
Subject: Re: [MO-java-dev] InterfaceImplementor


> My problem is with the autogeneration, but with what is being
generated.
> I'm not happy with having the stub classes which are gradually
> superseded, I think it could leave us with lots of classes which
> eventually serve no useful purpose.
>
> As a starting point for new mocks I don't have a problem with
generating
> the code, but creating stubs for everything is not something I'm happy
> with.
>
> But of course that's just my opinion, others may feel differently ;o)
>
> On Wed, 2002-04-17 at 13:25, Scott Lamb wrote:
> > On Wed, Apr 17, 2002 at 11:46:28AM +0100, Jeff Martin wrote:
> > > Thanks for this, but I'm not sure it's really the approach we want
to be
> > > taking. I'd prefer to keep things a bit cleaner even if that means
> > > having lots of methods with just notImplemented(); in them.
> >
> > I have to disagree - I don't think that's the clean approach. I
don't like the
> > idea of humans creating anything repetitive, anything that a
computer could
> > create. There's more possibility for error that way. Or even
copying/pasting
> > repetitive, automatically generated code. That code just serves to
obscure
> > where the real work is being done.
> >
> > > You might be interested in
> > > http://www.xpdeveloper.com/cgi-bin/wiki.cgi?MockMaker which takes
your
> > > approach a bit further.
> > >
> > > There is also some work being done on use java.lang.reflect.Proxy
to
> > > provide a default mock implementation. But I'm not aware of the
details
> > > of this yet.
> >
> > Those are both interesting. I'll look more at them.