Towards the Systematic Testing of Aspect-Oriented Programs

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

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

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

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

5. AOP Concepts-3 • Beforeadvice • 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. • Aroundadvice • 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.

6. Example

7. Example-2

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

9. More on AOP-2 Advantages of this approach • Modularity • Cohesion • Separation of concerns • Locality of change • A primary development goal is the production of high quality software. • AOPs must be tested for quality.

10. 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?

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

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

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

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

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

16. Changes in Control Flow

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

18. Open Questions-2 • How do we test aspects that interact with a core concern? • Developersneed to be able to determine how a core concernis affected by the execution of aspects • Important forboth 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 intoclass C. • All clients of C must also be modified toaccount for the new post-condition induced by anauthentication failure. • Could causea chaining of effects; clients of the clients of Cwould also require modification and so on.

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