RE: [MO-java-dev] DynaMock proxy toString issue

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

I don't believe so (I have done a little of this mock stuff before ;-). I w=
as trying to implement Chris's idea of using the matching infrastructure to=
 implement the special methods. It's not hard to code, but a pain to write =
the tests.=20

I also suspect that MockMaker generates too much stuff. There are 24 method=
s on MockCallFactory of which 4 are the supported interface. It has to be p=
ossible to simplify that.

S.

> These tests would work exactly as specified - I think the way you are try=
ing
> to solve the problem is wrong (e.g. you have misunderstood the metaphor t=
hat
> all the other tests are based on).
>=20
> Don't add the methods as defaults on construction (I think this would bre=
ak
> most objects in any design) - you just need to check if the method is
> toString, and if an expectation/match has been set on the mock for it.
>=20
> It is literally changing the following method in mock:
>=20
> private boolean isMockNameGetter(Method method, Object[] args) {
> 		return (method.getName().equals("toString")) && (args =3D=3D null);
> // to also check for expectation you need something like
> // && !calls.hasCall("toString",args);
> 	}
>=20
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf Of
> > Steve Freeman
> > Sent: 02 July 2003 04:08
> > To: moc...@li...
> > Subject: Re: [MO-java-dev] DynaMock proxy toString issue
> >
> >
> > Tim Mackinnon wrote:
> > > Not sure why the tests would be pain, isn't just a case of
> > adding the two
> > > following tests to mock?
> > >
> > > 	public void testProxyToStringWithNoToStringExpectation()
> > throws Exception {
> > > 		mockCallableAddable.addExpectedHasCall("toString",
> > METHOD_NOARG_ARGS);
> > > 		mockCallableAddable.setupHasCall(false);
> > >
> > > 		assertEquals("Should get mock name", MOCK_NAME,
> > mock.proxy().toString());
> > > 		mock.verify();
> > > 	}
> >
> > no. If the methods are added as defaults on Mock, during construction,
> > you have to fix the other tests so that calls to
> > MockCallFactory.createReturnStub() don't fail because it's short of a
> > return value. Which suggests that the callFactory is overspecified.
> >
> > > There is a smell, in some of the other tests because the
> > CallFactory is a
> > > bit over-used, it generates several types of stubs decorating
> > each other (so
> > > you have to set each of them up). I would say that this should be bet=
ter
> > > encapsulated so you just set one expectation on the
> > mockCallFactory - the
> > > tests would simplify and your code would be better.
> >
> > Exactly.
> >
> > S.
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> > _______________________________________________
> > 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