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
