Re: [aspectj-users] Re: [aspectj-dev] Testing advice blocks using reflec

[Adrian Colyer <adrian_colyer@xxxxxxxxxx>]

The old chestnut of naming advice eh?  :)

First thing to say is that we intend to do better in AspectJ 5 than 
require you to "reverse engineer" AspectJ code using standard Java 
reflection. Although this section of the developer's notebook is not 
written yet (nor is it implemented!), the intent is to provide a class 
"Aspect" analogous to the class "Class".  Aspect will provide methods like 
"getAdvice()", "getDeclaredAdvice()", "getPointcut()" etc. (It's logically 
a subclass of Class, although Class is final). Using the Aspect class will 
provide a means for tools like aUnit to query the structure of AspectJ 
programs without being dependent on application details. 

Now onto the question of identifying an individual piece of advice. There 
are two interesting questions here :- do you want to (probably yes, but 
worth some discussion), and if you do want to, how should you do it?

I can imagine using aUnit in a way that plays a series of mock join points 
at an *aspect*, and the tests verify that the aspect does the right thing 
in the presence of those join points. In this model, if more than one 
advice should execute as a result of a join point, the test should verify 
that all the advice expected to execute did, and that it produced the 
expected results etc.. This model has merits because it focuses on the 
unit of modularity (the aspect), and the input/output of that unit (join 
points and the effect of advice execution in this case).

Another use of aUnit might be to test at the individual advice level 
(could be in conjunction with testing in the above mode). Here you take 
the view that advice really is the smallest "unit" and the goal of unit 
testing is to verify correctness from the smallest unit upwards - 
therefore you need to identify individual advice methods.

My thoughts on that question had also led me to a meta-data based 
solution, possibly even an annotation defined by the AspectJ runtime such 
as org.aspectj.lang.annotations.AdviceName. Making it a "standard" 
annotation in this way opens up more possibilities for giving fine-grained 
control over the matching of advice execution join points. I'll post more 
on that soon....

Regards, Adrian.

-- Adrian
Adrian_Colyer@xxxxxxxxxx



Russell Miles <russellmiles@xxxxxxx> 
Sent by: aspectj-users-admin@xxxxxxxxxxx
12/01/2005 19:10
Please respond to
aspectj-users@xxxxxxxxxxx


To
aspectj-dev@xxxxxxxxxxx
cc
aspectj-users@xxxxxxxxxxx
Subject
[aspectj-users] Re: [aspectj-dev] Testing advice blocks using reflection, 
a tool users perspective question






Hmm, further thoughts on this have led me to source level meta-data - 
basically J2SE 5 annotations.

What about a solution like:

If a test developer wishes to test an advice block she adds a 
"standard" aUnit annotation to the block with a unique name as the only 
parameter so that the advice block can be identified. Then in the 
actual test code the advice can be invoked by meta name.

If aUnit is to be used with an earlier version of Java then numerical, 
source code ordering dependant route could be taken instead?

Thoughts?

Cheers,

Russ

On 12 Jan 2005, at 14:03, Russell Miles wrote:

> Hi everyone,
>
> I've hit an issue with how to invoke advice usefully from the unit 
> test method bodies in aUnit. What makes the most sense when it comes 
> to invoking the methods? How do we identify, by name, a specific 
> advice block that uses a different, or the same, set of pointcuts? 
> Don't want to tie this to source code ordering if possible. The 
> problem is:
>
> If I have an aspect such as:
>
> public aspect BeforeAdviceExampleAspect
> {
>    before() : within(BeforeAdviceExampleAspect) && 
> !within(BeforeAdviceExampleAspect)
>    {
>       System.out.println("Executing Before Advice");
>    }
>
>    before() : within(BeforeAdviceExampleAspect) && 
> !within(BeforeAdviceExampleAspect)
>    {
>       System.out.println("Executing Second Before Advice");
>    }
>
>    public void callMethod()
>    {
>       System.out.println("Called method on before advice");
>    }
> }
>
> Both advice blocks will select the same join point and their 
> signatures using un-enhanced AspectJ/Java reflection are:
>
> Advice block found: public void 
> aunit.tests.usecases.BeforeAdviceExampleAspect.ajc$before$aunit_tests_u 
> secases_BeforeAdviceExampleAspect$1$999acf7c()
> Executing Before Advice
>
> Advice block found: public void 
> aunit.tests.usecases.BeforeAdviceExampleAspect.ajc$before$aunit_tests_u 
> secases_BeforeAdviceExampleAspect$2$999acf7c()
> Executing Second Before Advice
>
> So, the ordering seems to be given by the $1 or $2 part of the name. 
> But apart from that there is no way to tell the advice blocks apart. 
> After reversing the order of the advice in the source aspect the 
> results looks like:
>
> Advice block found: public void 
> aunit.tests.usecases.BeforeAdviceExampleAspect.ajc$before$aunit_tests_u 
> secases_BeforeAdviceExampleAspect$1$999acf7c()
> Executing Second Before Advice
>
> Advice block found: public void 
> aunit.tests.usecases.BeforeAdviceExampleAspect.ajc$before$aunit_tests_u 
> secases_BeforeAdviceExampleAspect$2$999acf7c()
> Executing Before Advice
>
> This proves to me that the $1 and $2 are source code location 
> dependant; makes sense really. But this doesn't help in trying to 
> understand how developers could easily specify that they are testing a 
> particular piece of advice using regular Java syntax.
>
> Any suggestions from the community?
>
> Cheers,
>
> Russ
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users