Towards the Systematic Testing of Aspect-Oriented

Programs

R. Alexander, J.M. Bieman, and A. A. Andrews. Technical Report CS-4-105Colorado State University

2004

Presented by Carlos Acosta

Outline Aspect Oriented Programming

Concepts Example More on AOP

Questions Issues Potential Sources of Faults Classes of Potential Faults Proposed Testing Criteria Open Questions Conclusions

AOP Concepts Core concerns

Subject manner of the system. Constitute the domain information that

must be managed. Cross-cutting concerns

Concerns whose implementations must span across the core concerns.

Aspects The primary mechanism for defining

solutions to cross-cutting concerns Encapsulate behavior and state of those

crosscutting concerns

AOP Concepts-2 Pointcuts

Patterns Used to select elements (i.e. Join Points)

Join Points Well defined locations in the control flow of a

method of some concern Method calls, method execution, field access, and

object construction Advice

Method-like construct Express the cross-cutting actions that must take

place within the method body at the matched join point

Woven into the target concern May take one of three forms: before, after, and

around

AOP Concepts-3 Before advice

Instructions that must execute in the method body before execution of the element of the matched join point.

After advice Instructions that must execute after the element

corresponding to the matched join point has executed.

Around advice Instructions that, after weaving, surround

matched join point elements May alter the control flow and data dependencies

of the method. Can bypass the matched join point elements

altogether Can make the matched join point's execution

control dependent upon the around advice.

Example

Example-2

More on AOP AOP brings a unique set of benefits

and challenges. Increases modularity and cohesion,

understandability and maintenance. AOPs alter the development process.

Classes and methods of core concerns are developed and tested as before.

Instead of embedding the code for cross-cutting actions into method bodies, separate aspects are defined.

Aspects are woven into the classes. Once complete, the woven targets

should be the composite of behavior of both core and cross-cutting concerns.

More on AOP-2

Advantages of this approach ModularityCohesion Separation of concerns Locality of change

A primary development goal is the production of high quality software.AOPs must be tested for quality.

Questions

How do we adequately test aspect-oriented programs?

How do we know that our testing and quality objectives have been attained?

Is there some objective way to determine when we have tested enough?

Issues

Aspects do not have independent identity or existence.

Aspect implementations can be tightly coupled to their woven context.

Control and data dependencies are not readily apparent from the source code of aspects or classes.

Emergent behavior.

Potential Sources of Faults The fault resides in a portion of the

core concern that is not affected by a woven aspect.

The fault resides in code that is specific to the aspect, isolated from the woven context.

The fault is an emergent property created by interactions between one aspect and the primary abstraction.

The fault is an emergent property created when more than one aspect is woven into the primary abstraction.

Classes of Potential Faults

Incorrect strength in pointcut patterns

Incorrect aspect precedence Failure to establish expected

postconditions Failure to preserve state

invariants Incorrect focus of control flow Incorrect changes in control

dependencies

Proposed Testing Criteria Incorrect strength in pointcut patterns

Can cause the aspects to fail. Test of the aspect is required here.

Incorrect aspect precedence Occur when multiple aspects interact,

and are affected by the weave order. Testing all weave orders should reveal

these faults. Failure to establish postconditions

Can cause core concern methods to fail. Re-test all methods that have code

weaving using the original test set.

Proposed Testing Criteria-2 Failure to preserve state invariants

Can cause core concern methods to fail. Retesting of concern methods.

Incorrect focus of control flow Can cause advice to activate at the wrong

time. A criteria to reveal these faults may be a form

of condition coverage of point cut designators.

Incorrect changes in control dependencies These faults will affect core concern behavior. Retesting of concern methods.

Changes in Control Flow

Open Questions Are there ways to test aspects on their own?

Use the same coverage criteria on the woven target that was used to test the core concern.

Difficult since the weave process of many AOP languages weave directly to byte code

Analyze the byte code. Difficult to refer back to the source code of the core

concern and/or the aspects. Compiler optimizations increase the difficulty. Byte code may have no direct connection to core concerns

or aspects). Can we reverse engineer the weave process?

Work back through the weave steps in order to make a connection to the woven source artifacts.

Can we measure test coverage after weaving? Understand the types of coverage metrics that can be

reliability collected about individual aspects from the execution of a woven target.

Open Questions-2 How do we test aspects that interact with a

core concern? Developers need to be able to determine how a core

concern is affected by the execution of aspects Important for both testing and maintenance activities.

How do we test aspects that mutually interfere? Many aspects can be woven together It is possible for the aspects to interact in ways that

may not be apparent by examination of their source. How do we test aspects whose effects must

span more than one concern? Authentication policy enforcement, where an

authentication aspect will be woven into class C. All clients of C must also be modified to account for the

new post-condition induced by an authentication failure.

Could cause a chaining of effects; clients of the clients of C would also require modification and so on.

Conclusions AOP has potential for building the software

of the future AOP provides for separation of concerns,

maintainability, and evolvability Sound AOP construction methods and

systematic AOP testing Important step in broad acceptance of AOP as a

software development approach As a first step, we developed a candidate

fault model for AOPs and derived testing criteria Fault model needs to be empirically validated and

possibly extended and refined. Address open questions

This work is a first important step in developing an effective approach to the systematic testing of AOPs