1. Towards a Practical Approach to Testing Pointcut Descriptors With JQuati 1 LA-WASP 2009

2. By The Authors 2  Sandro Hiroki Tanaka  Emmanuel de Castro Santana  Eduardo Martins Guerra  Clovis Fernandez Torres  Fábio Fagundes Silveira

3. Agenda 3  Quick Conceptualization  The Problem  Causes  Task  Objectives  Using JQuati  Architecture and Components  Most Related Tools  Conclusion, Limitations and Future Developments  Source Code and Constribution

4. Testing on Aspect Orientation 4  Aspect Behavior Testing  Does it do what it proposes itself to do ?  Several approaches (data flow-based, machine state- based, petri nets-based, and UML model-based)

5. Testing on Aspect Orientation 5  Pointcut Descriptor Testing  Is this behavior being executed where and when it should ?  Three kinds of faults: too strong PCD, to weak PCD and both too strong and too weak PCD

6. The Problem 6  How to offer developers a practical and productive way to write test code to identify faults in pointcut descriptors, in a way to separate PCD testing and aspect behavior testing ?

7. Some Causes 7  Lack of ways to automatically trigger an advice and identify if a join point has been matched by a PCD.  In a test case that tests aspect behavior, usually it is not possible to conclude that a fault is due to an incorrectness in the PCDs.

8. Objectives 8  Allow the developer to define expectations regarding the execution of advices in a given test case and then identify faults from checking them against the actual executions.  Provide a intuitive syntax for developers to write test code specifically for PCD testing

9. Task 9  By using a new tool  Simulate execution contexts, i.e. join points to be matched by a group of PCDs.  Intercept advice executions.  Define and verify expectations related to advice execution given a set o join points.  By using additional metadata to test cases, integrate with existing testing tools

10. JQuati 10  A simple tool for testing PCDs integrated with jUnit  has it’s own Test Runner which controls the execution of each test case.  Allows the developer to generates classes in runtime using ClassMock for simulating execution contexts simply by adding metadata to the test class.  Allows the developer to define which advices should and which should not be executed in a test case through metadata added to the test method.

11. The tested Advice 11... public aspect FooBarAspect { @AdviceName(“interceptFoo") after() : execution(* *.foo(..)) { } @AdviceName(“interceptBar") after() : execution(* *.bar(..)) { } @AdviceName(“interceptFooBar") after() : execution(* *.fooBar(..)) { } } The annotation AdviceName should be added to the tested advice

12. JQuati - Simulating Execution Contexts 12.... @ExecutionContextCreation( classNames={“Foo",“Bar”}, methods={ "void foo()", "void bar(Integer)" } ) @RunWith(JQuatiRunner.class) public class AspectXTest { @ExecutionContextElement ClassExecutionContext cec;.... Defining which classes will be used for testing. These classes are created in runtime. The methods will be replicated to all classes on the classNames list. Methods can also receive parameters. JQuati Runner controlling the test cycle Element through which method in the generated classes will be called

13. JQuati - Testing 13.... @Test @MustExecute({“interceptFoo“,”interceptBar”}) @MustNotExecute({“interceptFooBar“}) public void shouldNotFooBarButFooAndBar() throws Exception { cec.executeMethodOnAll(“foo"); cec.executeMethodOnAll(“bar“, 0); cec.executeMethodOnClass("Foo", “bar", 0); }.... Expectations are defined by using the annotations MustExecute and MustNotExecute Every call to methods on the created classes should meet the expectations defined for the test method. The developer can make calls to one specific method of one specific Class or in all available Classes. Developers can use BDD naming conventions and better describe their intentions for where aspectual behavior should be inserted into.

14. JQuati – lets play !! 14

15. Architecture 15

16. Most Related Tools 16  AdviceTracer (Delamare et al, 2009)  APTE (Anbalagan e Xie, 2006)  AJTE (Yamazaki et al, 2005)

17. Contributions 17  A new tool to help developers describe their intentions for better addressing the business rules.  Path to new researches towards developing aspect oriented software with a test driven approach.

18. Some limitations 18  Triggering of advices not affected by reflection calls. In this case it is still possible to use real stub classes.

19. Future Developments 19  Improvements in JQuati  Automatic creation of aop-ajc.xml for the tests  Additional features in execution context creation  A way to choose which aspects to be woven in each test case  Ways to make the configuration easier  Additional research on JQuati  Solution of other problems on aspect orientation.  Case studies in industry.

20. Source Code and Colaboration 20  JQuati under LGPL and GPL  Shared on sourceforge: https://jquati.svn.sourceforge.net/svnroot/jquati  Evolution plan  Testing

21. Thank you all !!! Questions ? 21