Hi Otavio,
I'm glad you followed up. I tried to find your tool on Google and was
unable
to. Can you point me to a Web site and a way to download it?
Ron
-----Original Message-----
From: aspectj-dev-bounces@xxxxxxxxxxx
[mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Otávio Augusto L.
Lemos
Sent: Monday, March 28, 2005 3:14 AM
To: AspectJ developer discussions
Subject: Coverage Analysis tool for AspectJ -- Re: [aspectj-dev]
Examiningpointcut 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
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev