Re: [MO-java-dev] factorying calls on a per method basis?

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

I've written a tool that automatically generates all overloaded methods for
primitive types (i.e. it implements "autoboxing" in JDK's 1.4 and below.
Using the tool it is easy to add methods that set up different expectations:
expectOneOrMoreAndReturn, matchNameAndReturn, etc.

Cheers,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: "Tim Mackinnon" <tim...@po...>
To: "Barry Kaplan" <bk...@in...>
Cc: "Mockobjects-Java-Dev" <moc...@li...>
Sent: Friday, June 20, 2003 12:46 AM
Subject: RE: [MO-java-dev] factorying calls on a per method basis?


> We've been thinking about your problem... its an interesting one, which
has
> actually been quite rare over 4 years of development... but it seems a
> reasonable request.../
>
> anyway, I'm thinking that maybe match signatures should allow this level
of
> customization eg.
>
> myMock.expectAndReturn(OneOrMore.eq("getSomething", 12))
>
> vs.
>
> myMock.expectAndReturn(One.eq("getSomething", 13)).
>
> that is, the signature specifice the cardinality.
>
> Some of the other guys have also been thinking of:
>
> myMock.matchAndReturn(WildCardOne("get*", null)));
> myMock.expectAndReturn(One("getLenght", 12)));
>
> e.g. all geters will return null, but expect only one call the length
which
> will return 12.
>
>
> In retrospect after all of the refactoring, having method signatures as an
> oblect gives a possible the sweet spot that gives lots of interesting
> behavior?
>
> Tim
>
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf Of
> > Barry Kaplan
> > Sent: 19 June 2003 17:24
> > To: mockobjects
> > Subject: [MO-java-dev] factorying calls on a per method basis?
> >
> >
> > Often I find the need for a method to be called at least once, but its
> > ok if its called more times. Generally this is with a getter that is
> > providing a property used for some external purpose. What I end
> > up doing is:
> >
> > myMock.expectAndReturn("getSomething", 12);
> > myMock.matchAndReturn("getSomething", 12);
> >
> > While this works just fine, it gets to be a bit verbose at times.
> >
> > I know I can override the callable created by the 'expectAndReturn'
> > method by creating the mock with a custom factory. But the that factory
> > applies to all invocations of 'expect*'. What I would like is the
> > ability to define custom callables on a per-method basis. I guess like
> > the previous version allowed.
> >
> > Would it be so bad to have?:
> >
> > Mock.expectAndReturn(Callable callable)
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > 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.490 / Virus Database: 289 - Release Date: 16/06/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.490 / Virus Database: 289 - Release Date: 16/06/2003
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev