Towards the Systematic Testing of Aspect-Oriented Programs R. Alexander, J.M. Bieman, and A. A. Andrews. Technical Report CS-4-105 Colorado State University 2004 Presented by Carlos Acosta
Jan 05, 2016
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