Pushing the envelope

Darren's take on Java, agile methods, cool open source stuff, interesting technologies and other random wanderings through the land of blog.
Updated: 26/01/2003; 11:49:01.
Places to go
Apache Jakarta Project
c2.com
ExtremeProgramming.org
OpenSymphony
XProgramming.com
XP Developer

People to see
Russell Beattie
Eugene Belyaev
Tony Bowden
Mike Cannon-Brookes
Jeff Duska
Paul Hammant
Scott Johnson
Brett Morgan
Rickard Öberg
James Strachan
Joe Walnes

Things to do

Subscribe to "Pushing the envelope" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.


That was the day
October 2002
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Sep   Nov



Archives
December 2002
November 2002
October 2002
September 2002
August 2002

Listening To


Valid RSS

Click here to visit the Radio UserLand website.

  31 October 2002

Random Cliche

A brief aside from all the techno-babble.

You know how when you're on the other side of the world and you say where you're from people always say things like, "Oh, my second cousin Jake lives there, you must know them..."

Well in the spirit of the aforementioned, and in the knowledge that there are quite a few java bloggers in Sydney: My sister (Anna Hobbs) lives there and some of her friends are developers. Anyone reading this know her?

Hi Anna!


10:32:44 PM      comment []

MegaMocks

JMock is your friend...

[Joe's Jelly]

JMock does actually look quite similar to what I've done, but it is focussed more on the normal use of Mockobjects - ie. checking they were called with the expected values.

I'm not really doing Mocks at this point - its more like convincing an application that its running inside a real servlet container. Which means that I have to be able to understand that when I get a call like request.getHeader("user-agent"), I need to return "Fakezilla", but when I get request.getHeader("if-modified-since"), I have to return a valid date string, or null. I'm not trying to assert how the mocks are called, just fake up a convincing looking environment. What I've ended up with is essentially a form of dynamic dispatch, as each mock has a collection of MethodReceivers in a Map keyed by method name, and each MethodReceiver has a Map of MethodReturn objects, keyed by an ArrayList of the arguments. Its then a case of calling getReturnValue on the MethodReturn object (confused yet?). I can therefore return different responses based on the actual values (not just type) of the arguments.

I can also simply make the Mock return a hard-coded response directly where I can get away with it (methods with no arguments for example).

There's some syntactic ugliness in the setup code due to Java's lack of enclosures - the closest approximation I've found is to implement an interface 'in-place' with an anonymous block. The alternative is hundreds of really tiny and very similar looking concrete classes.

The whole thing isn't exactly generic or lightweight, as you have to know quite a lot about what your application is going to need in the way of parameters, and which methods its going to call on the request/response objects, but it has been quite illuminating finding out just how the application in question interacts with its environment.

And its nice to work on something a little off the wall every now and then :)


9:25:46 PM      comment []

© Copyright 2003 Darren Hobbs