AOSD 2005 BOFs

Posted on April 3, 2005

4


I attended four BOFs at AOSD 2005.

Testing Aspects. The practitioners at the session felt that TDD and testing aspects was quite natural and worked well. Many of us use JUnit to achieve this. Common themes include:

  • Making the aspects thin, so helper classes can be easily unit tested (e.g., to unit test advice).
  • Creating "test driver" static inner classes that exercise the right functionality. Note: these classes typically are like mocks in that they have no real behavior and track interactions, but are unlike mocks in that they have some control flow to expose join points. These exposed join points test cases that should match and shouldn’t match to test pointcut definitions. Some edge cases that may worth trying include handling subclasses, superclasses, even inter-type declarations (aka introductions).
  • Making aspects abstract, so test cases can include a static inner aspect that concretizes the pointcuts to make them apply to the test driver classes.
  • Testing tightly coupled aspects with their collaborators as a unit.
  • Use IoC to configure aspects (just like with objects).
  • Adrian noted that there are a whole bunch of little techniques for unit testing aspects, like using static inner aspects inside a TestCase and delegating to logic methods from inside advice. He also discussed the aUnit project, which he "announced" previously as a way of recruiting someone to build it. Russell Miles is currently working on it. I think it’s really a kind of mock framework for simulating join points. This kind of framework can help test advice, and could facilitate testing without having to place code in multiple packages. However, there’s a danger in not testing pointcuts by using the same specification for the pointcut as for the test.
    Adrian also noted that the AspectJ library will be a chance to show TDD for AOP.
  • Jonas noted that because AspectWerkz has named advice, it was easy to unit test it and mock it out also (note that you can use virtual mocks with adviceexecution to mock out AspectJ advice…).
  • There would be value in integrating use of aspects for testing with a jMock-style mocking framework.

Aspect libraries. There was a great deal of interest in creating reusable aspect libraries. I will post more about this BOF in a separate posting on the topic.

AspectJ 5. This started with Adrian demoing some of the cool new AspectJ 5 features. We discussed support for type patterns, and composability for type patterns and signatures. With the complexity of Java 5 generics, and the complexity of pointcuts for annotations, I think there needs to be an ability to name type patterns and also a verbose functional syntax for composing type patterns and signatures… We also support for type pattern – (Ramnivas demo’d a case where it would have helped).

Perobject BOF. This BOF was organized by Eric Bodden and Nicholas Lesiecki, to explore how to allow to use/extend AspectJ to associate aspects with instances.

One great outcome of this was an agreement in principle to implement dynamically enabled and disabled aspects at runtime for AspectJ. The basic idea is to allow an aspect to implement:

public interface Activation {
    boolean isAdviceEnabled();
    void setAdviceEnabled(boolean isEnabled);
}

For any aspect that implements this, the compiler will generate the default implementation (like an ITD), and will guard all the advice for that aspect with a test for …  && adviceEnabled. This test should be like a normal if test on a pointcut (i.e., be inlined in the method body), but it would reference the concrete aspect instance(s) that might match.

Adrian’s recently discovered pattern of using static inner aspects makes it feasible to instantiate a perthis aspect in a static context. This can help in some cases. Eric and Nick posted more thoughts on this to aspectj-users and Adrian showed an example which I’m sure he’ll be blogging soon.

Advertisements