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

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

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();
	}

	public void testProxyToStringWithToStringExpectation() throws Exception {
		final String result = "configured result";

		mockCallableAddable.addExpectedHasCall("toString", METHOD_NOARG_ARGS);
		mockCallableAddable.setupHasCall(true);
		mockCallableAddable.setupCall(result);

		assertEquals("Should get mock name", MOCK_NAME, mock.proxy().toString());
		mock.verify();
	}


Thus - the mockCallableAddable (and I will admit its badly named -the name
ideas was you can send calls to it but also add expectations and matches) -
would expect to be asked if it has a "toString" call (i.e. a call to a new
method called HasCall on CallableAddable), we configure the mock either true
or false, in the true case you also have to setup a result that you assert
should be true.

Its not a big deal.

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 better
encapsulated so you just set one expectation on the mockCallFactory - the
tests would simplify and your code would be better.

Its simply the tests reflecting a poor design decision made at 4:30pm on day
one. Actually it was a good decision then, becuase it meant we moved on - we
have not been good at refactoring the code - but this was a spare time
coding excercise.

Tim
> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Steve Freeman
> Sent: 01 July 2003 23:58
> To: moc...@li...
> Subject: Re: [MO-java-dev] DynaMock proxy toString issue
>
>
> chris cottee wrote:
> > I think there need to be some functional tests for Mock as well as the
> > mocked unit tests. Functional tests
> > are (in this case) better at expressing the intent of the code since
> > they are effectively examples of usage.
>
> Agreed. We've talked about writing some fit tests that would apply to
> both the java and C# versions.
>
> I'm beginning to find the current unit tests problematic too. I've been
> trying to add Chris's idea of just adding some default matches for
> methods like toString() and it's a right pain (and shouldn't necessarily
>   be visible in the tests).
>
> Chris are you implementing all this in 0.09. If so, I'll stop. Also, I
> suggest you break up your proposed additional unit tests into 4 specific
> tests, rather than one big one.
>
> Steve
>
>
>
> -------------------------------------------------------
> 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