[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-dev] Examining pointcut information on compiled sources or at runtime

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