RE: [MO-java-dev] InterfaceImplementor

[Tim M. <tim...@po...>]

Guys -

Am quite taken by the fact that people are using this stuff now - so the
discussions are interesting the contributions well received.

With regards to dynamic proxies - the idea is good, however I can't escape
the fact that having mock objects complain when you change things (e.g. they
break) has actually saved my bacon a number of times when refactoring or
making changes. It really drives home what will be affected. This could of
course be a different way of working so I am personally still considering
how it would change the way I code. At the moment I like the clean breaks
(eg. obvious compile errors).

Tim

-----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Steve Freeman
Sent: 17 April 2002 22:22
To: MockObjects
Subject: Re: [MO-java-dev] InterfaceImplementor


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.




_______________________________________________
Mockobjects-java-dev mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.349 / Virus Database: 195 - Release Date: 15/04/2002

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.349 / Virus Database: 195 - Release Date: 15/04/2002