RE: [MO-java-dev] Java Dynamic Mocks - going to Head?

[Vincent M. <vm...@pi...>]

Hi Tim,

I have been using the DynaMocks for a while now on several projects
(using CVS builds as there were no releases). I have not been following
very closely the changes you brought to the experimental branch. Are the
new DynaMocks very different from the other ones? How easy is it for me
to migrate? I guess I should take a look but I am very much in a hurry
and any help will be greatly appreciated. Maybe some docs about how to
use the new dyna mocks, etc?

Thanks
-Vincent

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
Tim
> Mackinnon
> Sent: 16 April 2003 10:23
> To: Mockobjects-Java-Dev
> Subject: [MO-java-dev] Java Dynamic Mocks - going to Head?
> 
> Guys -
> 
> First of all, sorry for missing Xtc - I've got the dynamic bug and
want to
> see the library in a state that it can be used in many projects. I
think
> its
> important to convey the power and simplicity of mocks (we all know
this,
> but
> there are so many bad examples out there...).
> 
> Anyway - I tried using the branch in the e2x codebase and as always,
on a
> real project there are often little subtleties that catch you out. As
John
> Nolan was around working on his own little pet project we bounced
ideas of
> each other to get things done.
> 
> Anyway - the library is working out quite well now and we should
consider
> rolling it in to the head stream soom! (Maybe a day or two more of "in
> usage" testing, and comments from anyone else who is interested - but
to
> be
> honest making it available in the head should allow greater changes).
> 
> Here are some points:
> 
> 1) To test the dynamic stuff, we used Traditional Mocks - it became a
pain
> hand coding them, especially on larger interfaces, so we took the
decision
> to use MockMaker. This worked well, however their are some ReturnXXX
> objects
> that it uses that should be in the base library. In the branch I have
just
> put them in - however they duplicate some existing functionality. I
propse
> we resolve this duplication in a second pass as it requires updates to
> code
> that mockmaker generates. Having the additional duplication allows an
> exisiting generated mock to be updated by simply removing 3 import
lines.
> To
> get a full solution we need to get all the tools running on a single
> platform - and you use the right one for the right job.
> 
> 2) The Callable interface has a "matches" method, this doesn't feel
right
> for all callables, its required for CallBag to operate - others don't
need
> it. This should be removed and implemented as a private decoration for
> CallBag.
> 
> 3) Steve's exellent suggestion of having:
> 
> Callable c1 = mock.expect("setContentType".....)
> Callable c2 = mock.expect("getWriter".....)
> c1.expectBefore(c2)
> 
> has not yet been implemented. This should work quite easily, but the
focus
> has been on UnorderdMock and OrderedMock.
> 
> 4) As you can use mocks as expected values themselves - there was some
> ugliness with the proxies needing to detect equality of mocks (you can
see
> this in the invoke method). I'm not sure if there is a better way to
do
> this.
> 
> 5) I think Mocks should probably register with something so that we
can do
> the Verifier.verify on both instance variables and local variables in
a
> test. I am still seeing lots of accidently unverified mocks
> 
> Overall the sample test case is looking very good (I have included it
> again
> below). How does everyone feel going ahead with a merge (I can
probably
> get
> Chris Cottee to help me merge it in at e2x)?
> 
> Tim
> 
> public void testDoGetNew() throws ServletException, IOException {
> 		Mock mockHttpServletResponse = new
> OrderedMock(HttpServletResponse.class,
> "response");
> 		Mock mockHttpServletRequest = new
> Mock(HttpServletRequest.class);
> 
> 		mockHttpServletRequest.matchAndReturn( "getParameter",
> C.args(C.eq("browser-identifier")), "MSIE-5.0" );
> 		mockHttpServletRequest.expectAndReturn( "getParameter",
> "subject", "Mail
> Subject" );
> // Alternative syntax
> 		mockHttpServletRequest.expectAndReturn( "getParameter",
> C.args(C.eq("body")), "Mail Body" );
> 
> 		final PrintWriter contentWriter = new PrintWriter(new
> StringWriter());
> 
> 		mockHttpServletResponse.expect( "setContentType",
> "text/html");
> 		mockHttpServletResponse.expectAndReturn( "getWriter",
> contentWriter );
> 
> // Still to do, instead of making response an OrderedMock
> //		CallMatch m1 = mockHttpServletResponse.expect(
> "setContentType",
> "text/html");
> //		CallMatch m2 = mockHttpServletResponse.expectAndReturn(
> "getWriter",
> C.args(), contentWriter );
> //		m1.expectBefore(m2);
> 
> 		SimpleServlet aServlet = new SimpleServlet();
> 		aServlet.doGet((HttpServletRequest)
> mockHttpServletRequest.proxy(),
> (HttpServletResponse) mockHttpServletResponse.proxy());
> 
> 		mockHttpServletRequest.verify();
> 		mockHttpServletResponse.verify();
> 	}
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.467 / Virus Database: 266 - Release Date: 01/04/2003
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev