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

[Russell Miles <russellmiles@xxxxxxx>]

Exactly the way I was going Adrian - great to hear that I'm not too far off in left field :)

I think aUnit should attack both approaches .. and off the top of my head I'm wondering if the coarser grained TestSuite should test an aspect in the mode you set forth in the first paragraph, and then TestCase could offer finer grained testing of the individual advice blocks using the second method. Not sure how well this sits with regular JUnit users or whether I may be pushing the TestSuite/TestCase analogies too far (that would be a terrible thing as it would only serve to confuse) but at first glance I like the separation between discrete advice testing (standard annotations potentially providing the means of identification) being built up into larger tests that off full join point variance testing. I'm just not sure if the cut should really be made between aUnit test suites and aunit test cases of not.

Cheers, looking forward to any more feedback I can get :)

Russ

On Tuesday, January 18, 2005, at 10:11AM, Adrian Colyer <adrian_colyer@xxxxxxxxxx> wrote:

>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
>
>
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>