towards the systematic testing of aspect oriented programs
Download
Skip this Video
Download Presentation
Towards the Systematic Testing of Aspect-Oriented Programs

Loading in 2 Seconds...

play fullscreen
1 / 19

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


  • 88 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Towards the Systematic Testing of Aspect-Oriented Programs' - gen


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

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
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
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
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
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
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
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
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
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
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
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
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
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.
open questions
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
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.
conclusions
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
ad