RE: [aspectj-users] Testing with JUnit

["Neil Hart" <neil@xxxxxxxxxxxx>]

Thanks for the response.  I like the declare-warning statement and will
check out the examples.

I am testing using JUnit; loving the automatic aspects of it.  I may not
have asked the question correctly.

Say I have classes Trade and Portfolio and PricedPortfolio.  I have
testcases TestTrade, TestPortfolio, and TestPricedPortfolio.

I then add an aspect StoreAspect to persist Trade and Portfolio.  Right now
I create TestTradeStore and TestPortfolioStore to test they work.  I would
like to create TestStoreAspect to add assertions to TestTrade and
TestPortfolio.

My worry is that if I rename Portfolio, both my StoreAspect and
TestStoreAspect will miss the pointcut but the test will succeed.  I also
worry that the StoreAspect may weave into PricedPortfolio and the test will
work.



-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx
[mailto:aspectj-users-admin@xxxxxxxxxxx]On Behalf Of Wes Isberg
Sent: Friday, September 26, 2003 12:37 PM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Testing with JUnit


We follow something like the approach you suggested.  How you
test of course depends on what you are trying to verify.

If the question is whether a static pointcut is working,
we set up a declare-warning statement for that pointcut and
expect the compiler to fail at the appropriate places.

Dynamic tests vary depending more based on what we're trying to
test than on the type of component being tested, but we can
usually verify results by logging arbitrary events
(e.g., a String including a particular value) and check for
expected events when done.  That tests both functionality
and dynamic sequence.  E.g.,

public class TestEvents {
     public void gotEvent(String s) { ... }
     public void expectEvents(String[] expected) { ... }
     public void checkAllEvents() throws ... { ... }
}

aspect TestStuff {
    private static final TestEvents testEvents;
    static {
         testEvents = new TestEvents();
         testEvents.expectEvents(new String[]
            {  "before [...] - target one"),
               "before [...] - target two")
            });
    }
    before() : ... {
        testEvents.gotEvent("before [...] - target " +
                              thisJoinPoint.getTarget());
    }
    ...
    after() returning : testInvocation() {
        testEvents.checkAllEvents();
    }
}

So setting up a dynamic test is a matter of:

- setting up the functional test
- setting up the join points and context to verify
   during the functional test
- calculating the expected events, usually by running the
   test, capturing the events, and verifying them manually
- setting up the event verifier to expect those events
   and fail if the events did not occur

That works for any kind of test -- unit, system, etc. Being
able to capture actual events and verify/state that they are
expected makes it pretty easy to specify even complex tests.
(It does mean you have to avoid run-specific String renderings,
such as the default Object.toString() implementation.)

For more examples, see the test-related modules in the AspectJ
CVS tree, especially the code in tests/ specified in
tests/ajcTests.xml.

Wes

Neil Hart wrote:

> I have a test suite for classes and aspects and I'm trying to figure out
the
> best way to construct the tests.  Currently I code a TestCase for each
woven
> piece of code.  I want to ensure that the code I think I've woven is
working
> correctly.  Ideally I'd like to write the aspect test cases as aspects
that
> get woven into a test case and a check that I've woven the correct code.
> Does anyone have any ideas or experiences with this?  Does what I said
make
> sense?
>
> TIA
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users