Re: [equinox-dev] How to test load-time-weaving with Equinox Aspects?

["Andrew Eisenberg" <andrew@xxxxxxxxxxxx>]

That's a question we've been struggling with for AJDT as we
incorporate EA into our project.

Bug 254606 https://bugs.eclipse.org/bugs/show_bug.cgi?id=254606
Discusses some part of this.  Not unit testing per se, but how we can
ensure that advice matches where you want it to.

To quote from the bug report:

<quote>
Weaveinfo messages are nice... but it would be great if they could
include more about the actual advice that is matching.  For example in
a testcase I have 10 pieces of advice with various pointcuts and a
comment next to each indicating whether they should match (or not).
When running a compile I just get a stream of weaveinfos that don't
include the info from the comment - its just a list of line numbers
for the matched join point and the advice, this is quite unhelpful.
Instead of:

before(): execution(* *(..)) && args(Foo) { // match exactly once with
no runtime test
}

I'd like to write:

@MatchCheck("1","should match with no runtime test")
before(): execution(* *(..)) && args(Foo) {
}

The weaver would verify the match count constraint and the extra text
would be included in the weave info message (or possibly in an error
message if the constraint is violated)

A count constraint obviously does not make sense for all situations
(eg. a trace aspect) but it would be nice to police some advice
targeted at specific locations:

@MatchCheck(">0")  // must match somewhere
@MatchCheck("1")   // must match one location
@MatchCheck("37")  // must match 37 locations

If the match count varies from the constraint we get a warning from the weaver.

</quote>

This obviously would test only the pointcuts, but it is possible to
use standard unit tests to test advice bodies.

Is this something that would be helpful?  Comment on the bug or send a
message to the aspectj users mailing list with your thoughts.

On Mon, Dec 15, 2008 at 6:07 AM, Heiko Seeberger
<heiko.reg@xxxxxxxxxxxxx> wrote:
> Jens,
>
> Very good question!
>
> To answer that we have to define what we mean with unit testing.
>
> If we really want to test the single units (classes and aspects) in
> isolation, we have to test the classes and aspects separately. As aspects
> themselves are hard (or not at all) testable, we have to write some testee
> classes which will be woven with the aspects.
>
> If we want to use JUnit or something like that in order to perform some kind
> of integration testing, we of course can take our aspects and the classes
> which are our intended targets for weaving altogether and see whether the
> woven code behaves as expected. As far as I can guess from what you wrote I
> think this is what you and your mate intend to do.
>
> Well, there is nothing special about running tests with Equinox Aspects. You
> have to use the same settings as for running systems with Equinox Aspects,
> i.e. specifying the framework extension, creating the aspect bundles etc. In
> the CVS there are some examples ...
>
> Cheers
> Heiko
>
> On 15.12.2008, at 13:24, Jens Goldhammer wrote:
>
>>
>> Hello mailing list,
>>
>> we have successfully integrated some aspects in our eclipse rcp product.
>> That´s really fine because it prevents us from stupid work to log each
>> method :-)
>>
>> A member of my development team controls the junit tests and wants me to
>> write some tests to see that the aspects are working. How can I do that?
>> Is
>> there something special for aspect testing?
>>
>> Thanks,
>> Jens
>> --
>> View this message in context:
>> http://www.nabble.com/How-to-test-load-time-weaving-with-Equinox-Aspects--tp21012981p21012981.html
>> Sent from the Equinox - Dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>