Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Coverage Analysis tool for AspectJ -- Re: [aspectj-dev] Examining pointcut information on compiled sources orat runtime

Hi all,

  I was at the AOSD discussion session on testing and I know that some of
you were also there. I apologize the self promotion but I think it would be
nice if more people were aware of our work since we´ve only published at the
AOSD Workshop on Testing so far, and not everybody was there. We have
implemented a tool for coverage analysis of AspectJ programs based on the
bytecode and defined some special AO structural testing criteria and def-use
graph. The AO Def-Use graph explicitly shows the points where pieces of
advice are executed using special nodes. It is a graphical representation of
the control and data flow of the units of AspectJ programs and can help in
understanding the interactions among aspects and units that they define
behavior through advice.

  If anyone is interested in knowing more about it, please feel free to send
me an email and I'll send the paper and presentation. The cool thing is that
the tool can also work together with frameworks such as aUnit, because the
aspects are instrumented separately and the tool support the import of JUnit
test cases.

Regards,
Otavio Lemos

----- Original Message ----- 
From: "Russell Miles" <russellmiles@xxxxxxx>
To: <aspectj-dev@xxxxxxxxxxx>
Sent: Monday, March 28, 2005 7:20 AM
Subject: [aspectj-dev] Examining pointcut information on compiled sources
orat 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
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev



Back to the top