[MO-java-dev] [IDEA] Supporting runtime Mock swap in

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

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