mockobjects-java-dev

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

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

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

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

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

Sorry for being incomunicado for the last few days.  I haven't had a chance
to see the latest changes -- it seems next to impossible to get BT to
acknowledge that they can install a phone line to my boat let alone
broadband! I'd like the chance to meet up and check out / comment on the
latest updates.  Are you (Tim) going to be at XTC this week?  Perhaps we
could hammer out the CallSequence class.

> 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.

For a CallSequence it will also need a "complete" method that returns true
if the Callable can be removed from the front of the sequence.  Personally,
I feel comfortable having these methods in the Callable interface, but if
the Decorator approach works that will be great.

> 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.

In the new design, this would be accomplished by organising "setContentType"
and "getWriter" into a CallSequence and adding the call sequence to the
Mock.

CallCollection seq = mock.expectSequence();
seq.expectVoid( "setContentType", ... );
seq.expectAndReturn( "getWriter", ... );

The expectBefore method will be quite messy to implement in the current
design.  Since there is already a way to achieve the same effect, I'd
suggest not implementing expectBefore.

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

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

Nat Pryce wrote:
>>Callable c1 = mock.expect("setContentType".....)
>>Callable c2 = mock.expect("getWriter".....)
>>c1.expectBefore(c2)
>>
> In the new design, this would be accomplished by organising "setContentType"
> and "getWriter" into a CallSequence and adding the call sequence to the
> Mock.
> 
> CallCollection seq = mock.expectSequence();
> seq.expectVoid( "setContentType", ... );
> seq.expectAndReturn( "getWriter", ... );
> 
> The expectBefore method will be quite messy to implement in the current
> design.  Since there is already a way to achieve the same effect, I'd
> suggest not implementing expectBefore.

We went round this a few times in discussion. We can think of three 
common cases:
- I don't care about the order:
     Mock
- I care about the whole sequence:
     OrderedMock
- I don't care about the order /except/ for these two:
     Mock plus annotations.

The problem with getting the sequence is how to relate it to the rest of 
the expectations? And I wanted to avoid having toggles and state and 
general complication. The implementation is actually quite easy if the 
Calleable supports a hasBeenCalled() property (we did it in the old 
version). And (to me, at least) it's easier to read.

S.

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

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

The way it would work is that the sequence would be added to the mock and
therefore be checked to see if it matched any incoming call.  The sequence
would match if the callable at its head matched.  Once the callable
hasBeenCalled, the head would be dequeued and the sequence would then match
subsequent calls against the new head.  This achieves the current behaviour,
makes it easier to define sequences of more than two calls, allows more
flexible combinations of sequences and selections, and does not need any
changes to the mock class itself because all code to deal with sequences is
in the CallSequence class, and just "falls out" of the current design.

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

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: "Mockobjects-Java-Dev" <moc...@li...>
Sent: Wednesday, April 16, 2003 12:17 PM
Subject: Re: [MO-java-dev] Java Dynamic Mocks - going to Head?


> Nat Pryce wrote:
> >>Callable c1 = mock.expect("setContentType".....)
> >>Callable c2 = mock.expect("getWriter".....)
> >>c1.expectBefore(c2)
> >>
> > In the new design, this would be accomplished by organising
"setContentType"
> > and "getWriter" into a CallSequence and adding the call sequence to the
> > Mock.
> >
> > CallCollection seq = mock.expectSequence();
> > seq.expectVoid( "setContentType", ... );
> > seq.expectAndReturn( "getWriter", ... );
> >
> > The expectBefore method will be quite messy to implement in the current
> > design.  Since there is already a way to achieve the same effect, I'd
> > suggest not implementing expectBefore.
>
> We went round this a few times in discussion. We can think of three
> common cases:
> - I don't care about the order:
>      Mock
> - I care about the whole sequence:
>      OrderedMock
> - I don't care about the order /except/ for these two:
>      Mock plus annotations.
>
> The problem with getting the sequence is how to relate it to the rest of
> the expectations? And I wanted to avoid having toggles and state and
> general complication. The implementation is actually quite easy if the
> Calleable supports a hasBeenCalled() property (we did it in the old
> version). And (to me, at least) it's easier to read.
>
> S.
>
>
>
>
> -------------------------------------------------------
> 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

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

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

No problems Nat - we have made some good progress, and things are pretty
much how you would expect them. Mostly like your diagram but a few things
haven't materialised as you drew them yet (I forget which, but it was
trivial).

I'm not going to be at XtC next week as I am in America for two weeks
(leaving this Sunday). If you are near Liverpool St. today (Thurs) give me a
call and drop by the e2x offices.

CallSequence has been completed - so no need to worry on that one. The last
big one is ANY_ARGS - it should be an object in its own right (we shouldn't
use Constraint[] in a CallMatch it should be a Contraints object with an
interface which AnyContraints can implement and just always return true ).

The callable interface may be ok - I'm divided on this one - we can discuss
it later.

As for the before/after idea - I like how the functional test proposes it.
It should be easy to implement too - just decorate an ExpectedCall with a
before field - when you call, make sure the before object wasCalled (may
need to add wasCalled to the Callable interface though).

Anyway - the current stuff is very usuable for most cases now, I'm really
enjoying using it.

Tim

-----Original Message-----
From: Nat Pryce [mailto:nat...@b1...]
Sent: 16 April 2003 11:08
To: Tim Mackinnon; Mockobjects-Java-Dev
Subject: Re: [MO-java-dev] Java Dynamic Mocks - going to Head?


Sorry for being incomunicado for the last few days.  I haven't had a chance
to see the latest changes -- it seems next to impossible to get BT to
acknowledge that they can install a phone line to my boat let alone
broadband! I'd like the chance to meet up and check out / comment on the
latest updates.  Are you (Tim) going to be at XTC this week?  Perhaps we
could hammer out the CallSequence class.

> 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.

For a CallSequence it will also need a "complete" method that returns true
if the Callable can be removed from the front of the sequence.  Personally,
I feel comfortable having these methods in the Callable interface, but if
the Decorator approach works that will be great.

> 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.

In the new design, this would be accomplished by organising "setContentType"
and "getWriter" into a CallSequence and adding the call sequence to the
Mock.

CallCollection seq = mock.expectSequence();
seq.expectVoid( "setContentType", ... );
seq.expectAndReturn( "getWriter", ... );

The expectBefore method will be quite messy to implement in the current
design.  Since there is already a way to achieve the same effect, I'd
suggest not implementing expectBefore.




---
Incoming 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

---
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

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

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

About time someone had the time to finish up the library!

Here's some things I think we ought to do:

- announce on MO-java-users, I have no idea whether anyone out there is
using this stuff.

- it would be really, really nice if someone would volunteer to help
clean up the build. It's lotsa fun to write new features, but there's
some boring stuff to do as well. In particular, we need to split out the
website and maybe move to the Wiki that Joe's so kindly set up.

- there's also a noticeable amount of duplication in the code. Who will 
take responsibility for tidying it up after the initial commit?

- Jeff, I'd like to pull the alt code out as a separate library. What do
you think?

Tim Mackinnon wrote:
> 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
> [...]

How about moving the mockmaker stuff into a holding package, or at least 
commenting it? Right now it's confusing and there are no cues for what 
to use.

> 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.

How else can we tell if an incorrect method call has been made? I 
thought that was part of what matches did?

> 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.

Can we have an example of how this is used? Also, what's this 
"getMockName" thing?

> 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

you mean (gasp) a global collection? Is this a problem because of the 
structure of your tests?

S.

-- 
"A LISP programmer knows the value of everything but the cost of nothing.
  A C programmer knows the cost of everything but the value of nothing."
(Todd Proebsting)

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

[Jeff M. <je...@mk...>]

> - Jeff, I'd like to pull the alt code out as a separate library. What do
> you think?

Fine by me, only thing of note is that moving forward I'd like to use
the convension of project-library-version.jar for jars as this fits the
rpm system.

e.g. mockobjects-core-0.8.jar not mockobjects-0.8-core.jar

-- 
Jeff Martin <je...@mk...>

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

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

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
> Jeff Martin
> Sent: 16 April 2003 13:57
> To: MockObjects
> Subject: Re: [MO-java-dev] Java Dynamic Mocks - going to Head?
> 
> 
> > - Jeff, I'd like to pull the alt code out as a separate library.
What do
> > you think?
> 
> Fine by me, only thing of note is that moving forward I'd like to use
> the convension of project-library-version.jar for jars as this fits
the
> rpm system.
> 
> e.g. mockobjects-core-0.8.jar not mockobjects-0.8-core.jar

+10! I have to rename the jars whenever I upload them to the Maven
ibiblio repository! (http://www.ibiblio.org/maven/mockobjects/jars/).

Thanks
-Vincent

> 
> --
> Jeff Martin <je...@mk...>
> 
> 
> 
> -------------------------------------------------------
> 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

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

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

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

Hi Vincent - thanks for chipping in, it was on the ToDo list to catch up
with you and see how the changes would impact you as well. (If anyone else
is using it - please speak up as well).

Basically the library is pretty similar to before however when using it when
working with e2x i noticed that the TDD experience wasn't as good as it
should be - the use of a separate CallSequence to order calls or have
multiple calls to the same method wasn't very intuitive. Also the error
messages that you got back when things failed were not easy to interpit. I
worked with Nat and then Steve to get something that seems to satisfy
everyone so far.

I ported the e2x codebase in about an hour - and some of that time were
actually flaws in tests that the old library sort of covered up (some of
these were mocks expecting other mocks as parameters, so you might not even
experience this.

It would be really good if you could port to the new one (I still shudder
from my Connextra experience of the old mock library being so diverged we
never were able to go back).

The following is a fragment of how you would have written a simple servlet
test:

	public void testDoGetOldStyle() throws ServletException, IOException {
		Mock mockHttpServletResponse = new Mock(HttpServletResponse.class);
		Mock mockHttpServletRequest = new Mock(HttpServletRequest.class);


		CallSequence params = new CallSequence();
		params.expectAndReturn( new Constraint[] { C.eq("body") }, "this is the
body" );
		params.expectAndReturn( new Constraint[] { C.eq("subject") }, "mail from
tim" );
		params.expectAndReturn( new Constraint[] { C.eq("recipients") },
			new String[] { "nat...@b1...", "st...@m3..." } );

		mockHttpServletRequest.expect( "getParameter", params );

		SimpleServlet aServlet = new SimpleServlet();
		aServlet.doGet((HttpServletRequest) mockHttpServletRequest.proxy(),
			(HttpServletResponse) mockHttpServletResponse.proxy());

		mockHttpServletRequest.verify();
		mockHttpServletResponse.verify();
	}


The following is how you would now write it (with a few extra features and
examples shown as well):

	public void testDoGetOldStyle() throws ServletException, IOException {
        	Mock mockTimer = new Mock(Timer.class);
		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" );
		mockHttpServletRequest.expectAndReturn( "getParameter",
C.args(C.eq("body")), "Mail Body" );
        	mockTimer.expectAndReturn("getTime", 10000);
        	mockTimer.expectAndReturn("getTime", 20000);

		final PrintWriter contentWriter = new PrintWriter(new StringWriter());

		mockHttpServletResponse.expect( "setContentType", "text/html");
		mockHttpServletResponse.expectAndReturn( "getWriter", C.args(),
contentWriter );

// proposed arbitrary odering implementation
//		CallMatch m1 = mockHttpServletResponse.expect( "setContentType",
"text/html");
//		CallMatch m2 = mockHttpServletResponse.expectAndReturn( "getWriter",
contentWriter );
//		m1.expectBefore(m2);

		SimpleServlet aServlet = new SimpleServlet((Timer)mockTimer.proxy());
		aServlet.doGet((HttpServletRequest) mockHttpServletRequest.proxy(),
			(HttpServletResponse) mockHttpServletResponse.proxy());

		mockHttpServletRequest.verify();
		mockHttpServletResponse.verify();
		mockTimer.verify();
	}


Basically to port:

references to CallSequence will break (its now an interenal object that
shouldn't be used). Take each of the expectAndReturn lines and just run them
against a Mock (like we with the mockHttpServletRequest) and then remove the
sequence.

Mock.expect doesn't take a calls object - its like expectVoid (see below).

You can choose between Mock and OrderedMock - to decide if you want set like
(any order calls) or list like behavior. They both have expect,
expectAndReturn, expectAndThrow style methods, along with match... methods
(this latter is for returning a value for a method signature that matches).

YOUR OPINION? For void methods, we have used expect("aVoidMethod"... in the
old library this was called expectVoid(... There is a deprecated version in
there to help porting - whats your opinion on the rename to just expect?
(The issue is - for true consistency it should be ExpectAndVoid - but if you
aren't expecting any return value or exception why put that in the name?
Shorter seems better?).

FUTURE:
 Error messages are much better - they still can be improved.
 Mocks that takes mocks as expect parameters give strange errors if you
forget to use mock.proxy (we could overload this and do the .proxy
automatically?)
 You can see the example of how we might do call odering for better
precision
 C.ANY_ARGS is currently removed - use C.anyArgs(argCount) - becuase of the
proper signature overloading using null is a problematic. ANY_ARGS should be
a proper object not an array.
 It may be useful to have a CallSubSetMock and a CallSubListMock (which
probably means OrderedMock should be renamed to CallListMock)

Hope this helps.

Tim

-----Original Message-----
From: Vincent Massol [mailto:vm...@pi...]
Sent: 16 April 2003 18:45
To: 'Tim Mackinnon'; 'Mockobjects-Java-Dev'
Subject: RE: [MO-java-dev] Java Dynamic Mocks - going to Head?


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


---
Incoming 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

---
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