I'm trying to get a build of the latest MockObjects code base using
Eclipse. I've connected to the CVS repository and checked things out and
tried to build things using Ant, but I'm having problems getting the code
to compile. My current problem involves references to JUnit. I'm sure I
can come up with a way to make the thing build in Eclipse, but it would
seem that all I should have to do is check things out in from CVS and do an
Ant build. Are there any other specific things I need to setup/configure
in Eclipse to make the Ant build script work correctly?
Thanks.
--
James Howe

Hi,
I've been thinking about the features of AgileTest (from Polygenix). I
think there's an easy way to support the same feature (which would be
just great for most mockobjects users). It's by using a java AOP
framework.
For example, look at AspectWerkz: http://aspectwerkz.sourceforge.net/
(see http://freeroller.net/page/jboner/20030416 for an example of how to
use it to code a cache).
Imagine you have the following piece of code:
public myMethod(.)
{
[.] = SomeClass.getXXX() ;
}
where getXXX() is static. Or anything else for that matter. The goal
here is to introduce the Mocks in the class being tested. We usually do
this using refactoring and providing setters/constructors/etc. And again
this is the best practice. However, in some cases, like when you inherit
from a legacy application, you can't easily break everything and
refactor it all.
Then imagine the following (using AspectWerkz):
public class TestAdvice extends MethodAdvice
{
public TestAdvice()
{
super();
}
public Object execute(final JoinPoint joinPoint)
throws Throwable
{
return [whatever is needed for the test];
}
}
Where "whatever is needed for the test" would be setup using the same
kind of API (setupXXX, etc) like our current Mock (AspectWerkz supports
dynamically addition of interfaces, methods and fields to existing
classes).
From what I currently understand, AspectWerkz needs an XML descriptor to
tell where to apply the advice. Something like:
<advice name="testing"
class="...TestingAdvice"
deploymentModel="perInstance"/>
<aspect class=".*">
<pointcut type="method" pattern="ce qu'on veut trapper">
<advice-ref name="testing"/>
</pointcut>
</aspect>
But I haven't checked and it may also support a java API (as does the
JBoss AOP fwk) to dynamically create aspects which would make it even
easier for users to declare where swap-ins should occur.
My example is a bit rough and is far from a real implementation but I
hope it gives some ideas of what I mean. With AspectJ it was a bit
awkward as it introduces a new langage which needs a post compiler,
changes to the build system, is not IDE-friendly, etc. With the new AOP
frameworks like AspectWerkz or others, I think AOP for unit testing is
really a boon.
And we should probably explore it, don't you think? :-). I'll certainly
explore these new frameworks for Cactus in order to be able to intercept
calls in the container.
Thanks
-Vincent

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.pryce@...]
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

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.pryce@...", "steve@..." } );
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:vmassol@...]
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: mockobjects-java-dev-admin@...
> [mailto:mockobjects-java-dev-admin@...] 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
> Mockobjects-java-dev@...
> 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