Towards a Practical Approach to Testing Pointcut Descriptors With JQuati

1

LA-WASP 2009

By The Authors2

Sandro Hiroki Tanaka Emmanuel de Castro Santana Eduardo Martins Guerra Clovis Fernandez Torres Fábio Fagundes Silveira

Agenda3

Quick Conceptualization The Problem Causes Task Objectives Using JQuati Architecture and Components Most Related Tools Conclusion, Limitations and Future

Developments Source Code and Constribution

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)

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

The Problem6

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 ?

Some Causes7

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.

Objectives8

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

Task9

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

JQuati10

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.

The tested Advice11

...

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

JQuati - Simulating Execution Contexts

12

....

@ExecutionContextCreation(classNames={“Foo",“Bar”},methods={

"void foo()","void bar(Integer)"

})@RunWith(JQuatiRunner.class)public class AspectXTest {

@ExecutionContextElementClassExecutionContext 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

JQuati - Testing13

....

@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.

JQuati – lets play !!14

Architecture15

Most Related Tools16

AdviceTracer (Delamare et al, 2009) APTE (Anbalagan e Xie, 2006) AJTE (Yamazaki et al, 2005)

Contributions17

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.

Some limitations18

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

Future Developments19

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.

Source Code and Colaboration

20

JQuati under LGPL and GPL Shared on sourceforge:

https://jquati.svn.sourceforge.net/svnroot/jquati

Evolution plan Testing

Thank you all !!!

Questions ?

21