[aspectj-dev] Examining pointcut information on compiled sources or at r

[Russell Miles <russellmiles@xxxxxxx>]

Hi everyone,

I've got the first API code of aUnit up now on sourceforge (see 
http://www.aunit.org) but now I'm in deep with the task of how to 
actually implement the API and how it will run test join point contexts 
against specified aspects. I've got a couple of strategies as to how to 
do this but the best one would be if there was a reasonably simple 
means of examining the pointcut logic for a particular piece of advice 
at runtime (i.e. as the test is being run). But, is this pointcut 
information lost after compilation? At the moment this seems to be the 
case and in the past maintaining this pointcut information might not 
have made sense anyway. But in running unit tests I need to examine the 
advice blocks and then figure out which ones should be triggered using 
the test join point context (according to pointcut declarations, 
precedence, parameters etc) but without that information to hand at 
test runtime I'm a bit stumped. Any thoughts?

The other strategy would be to allow an additional test-based meta 
description of an aspect, using annotations, that could be explicit or 
aspect introduced, which would provide wildcard-like classifiers to the 
test engine at runtime that would then allow the test developers to 
specify which advice blocks are to be triggered according to a specific 
join point context. This is not quite the same as 'named advice 
blocks', where the advice would be explicitly invoked by the test, it 
is more of a means for the test engine to support some logic that would 
allow it to decide at runtime which advice block should be triggered by 
a join point context.  While I think this would work, it doesn't feel 
as good as relying on the actual pointcut declarations that are 
available in the source. Any thoughts on that one?

At the moment I can implement the second method but if anyone has a 
strategy as to how the first method (just relying on pointcut 
declarations that are somehow available at runtime) then please let me 
know.

As a final note, here are the drivers and constraints that I currently 
see on aUnit test developers:

As a test developer you can create a TestStep that contains a specific 
context against which your aspect is to be tested. Using the first 
method (pointcut based if available at runtime) you can then supply the 
context to the test framework and it will trigger the appropriate 
advice blocks with the right precedence and other rules. Using the 
second method, you will also need to provide a Selector in the TestStep 
that will be used to compare the meta-data for the advice blocks inside 
your aspect with the selector to allow the test framework to initiate 
the right advice blocks (maintaining parameters and precedence rules as 
before). You can also test multiple aspects or environments using 
threads by setting up more complex tests (this is not seen as the job 
of the framework which is merely providing the TestStep runtime 
bridging to the aspects).

Any thoughts on any of this would be greatly appreciated :)

Cheers,

Russ