Towards the systematic testing of aspect oriented programs
Sponsored Links
This presentation is the property of its rightful owner.
1 / 19

Towards the Systematic Testing of Aspect-Oriented Programs PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

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. Outline. Aspect Oriented Programming Concepts Example More on AOP Questions Issues

Download Presentation

Towards the Systematic Testing of Aspect-Oriented Programs

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

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


Presented by Carlos Acosta


  • 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

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



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

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

  • 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?


    • 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?

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


    • 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

  • Login