Towards a Practical Approach to Testing Pointcut Descriptors With JQuati

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

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

3. Agenda • QuickConceptualization • TheProblem • Causes • Task • Objectives • Using JQuati • ArchitectureandComponents • MostRelatedTools • Conclusion, Limitationsand Future Developments • Source CodeandConstribution

4. Testing on Aspect Orientation • 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 • 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 • 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 • 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 • Allow the developer to define expectations regarding the execution of advices in a given test case and then identifyfaults from checking them against the actual executions. • Provide a intuitive syntax for developers to write test code specifically for PCD testing

9. Task • 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 • 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 The annotation AdviceName should be added to the tested advice ... public aspect FooBarAspect { @AdviceName(“interceptFoo") after() : execution(* *.foo(..)) { } @AdviceName(“interceptBar") after() : execution(* *.bar(..)) { } @AdviceName(“interceptFooBar") after() : execution(* *.fooBar(..)) { } }

12. JQuati - SimulatingExecutionContexts Definingwhich classes willbeused for testing. These classes are created in runtime. Themethodswillbereplicated to all classes ontheclassNameslist. Methods can also receive parameters. • .... • @ExecutionContextCreation( • classNames={“Foo",“Bar”}, • methods={ • "void foo()", • "void bar(Integer)" • } • ) • @RunWith(JQuatiRunner.class) • public class AspectXTest { • @ExecutionContextElement • ClassExecutionContext cec; • .... JQuati Runnercontrollingthetestcycle Elementthroughwhichmethod in thegenerated classes willbecalled

13. JQuati - Testing Expectations are definedbyusingtheannotationsMustExecuteandMustNotExecute .... @Test @MustExecute({“interceptFoo“,”interceptBar”}) @MustNotExecute({“interceptFooBar“}) public void shouldNotFooBarButFooAndBar() throws Exception { cec.executeMethodOnAll(“foo"); cec.executeMethodOnAll(“bar“, 0); cec.executeMethodOnClass("Foo", “bar", 0); } .... Everycall to methodsonthecreated classes shouldmeettheexpectationsdefined for thetest method. The developer can make calls to one specific method of one specific Class or in all available Classes. Developerscan use BDD namingconventionsandbetterdescribetheirintentions for whereaspectualbehaviorshouldbeinsertedinto.

14. JQuati – lets play !!

15. Architecture

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

17. Contributions • 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 • Triggering of advices not affected by reflection calls. In this case it is still possible to use real stub classes.

19. Future Developments • 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 • JQuati under LGPL and GPL • Shared on sourceforge: https://jquati.svn.sourceforge.net/svnroot/jquati • Evolution plan • Testing

21. Thank you all !!! Questions ?