Transcript Document
ASTA
Aspect Software Testing Assistant
Juha Gustafsson,
Juha Taina,
Jukka Viljamaa
University of Helsinki
Motivation
Cross-Cutting Concerns in Software
Implementation modules
Security
Logging
Persistence
Cross-cutting
concerns clutter
the main class
model
2/21
Logger
out: OutputStream
log(s: String)
3/21
An Example
Money Transfer: Logical Level
void transfer(Account from, Account to, int amount) {
if (from.getBalance() < amount) {
throw new InsufficientFundsException();
}
}
from.withdraw(amount);
to.deposit(amount);
4/21
An Example
Money Transfer: Implementation Details
void transfer(Account from, Account to, int amount) {
if (!getCurrentUser().canPerform(OP_TRANSFER)) {
throw new SecurityException();
}
Security
}
Transaction tx = database.newTransaction();
if (from.getBalance() < amount) {
tx.rollback();
throw new InsufficientFundsException();
}
Persistence
from.withdraw(amount);
to.deposit(amount);
Logging
systemLog.logOperation(OP_TRANSFER, from, to, amount);
tx.commit();
5/21
Solution
Aspect-Oriented Programming (AOP)
Separating cross-cutting concerns from the
core concerns (i.e. from the main class model)
Aspect = a definition of a cross-cutting concern
pointcut
= a pattern that selects join points
(i.e. elements that appear in method bodies)
advice = a method-like construct that is executed
in the selected join points (before, after, around)
weaving = the process of attaching advice to the
appropriate join points
6/21
An example AOP program
HelloWorld in the AspectJ language
Go to http://www.eclipse.org/ajdt/ …
… and watch the demo!
7/21
A new question arises
How to test AOP?
Do we test what we intend to test?
How
to prioritise our tests?
How to pick a good testing strategy?
When should we stop testing?
In AOP these are especially difficult questions
because
the
execution context of an aspect depends on the
(internal implementation of the) class it is woven to
relating a failure to the fault that causes it is difficult
the control and data flows are not explicit
a particular aspect weave order can cause problems
8/21
A new question arises
How to test AOP?
Visualising AOP testing is not straightforward
what
kinds of test coverage criteria to use and
visualise (is it sufficient to show that we have visited
an aspect once, how to show the weaving context)?
current control flow graphs are insufficient to visualise
the test execution paths in the presence of aspects
high-level coverage visualisation for AOP testing is a
completely open question
Yet, visualisation of AOP testing is (at least) as
important as visualisation of traditional (OO)
testing
9/21
Testing AOP
Fault Sources
Fault in the core concern code
Fault in the (context independent) aspect code
Fault created by interactions between the aspect
and the core concern code
Fault created when more than one aspect is
woven into the core concern code
10/21
Testing AOP
[Alexander, Bieman, Andrews, 2004]
Fault Model & Additional Testing Required
Incorrect strength in pointcut patterns
Incorrect aspect precedence
use the original test set to re-test all methods that have the aspect
Failure to preserve state invariants
use a form of condition coverage of pointcut designators
Failure to establish expected postconditions
test all weave orders
Incorrect focus of control flow
test the aspect
same as in previous
Incorrect changes in control dependencies
same as in previous
11/21
AOP Testing Theory
Coverage criteria
Coupling metrics
Control flow formalism
…
12/21
Tool Support
Tool support is essential for systematic testing
Not many tools exist for AOP testing
coverage
tools
visualisation tools
scripting languages & environments to automate AOP
testing
13/21
Research Background
Due to project RITA (fRamework Intgration and
Testing Application) we have a strong
background in white-box test execution and
analysis
RITA is intended for product family testing, but
similar ideas and issues arise in AOP testing
RITA as a prototype is not suitable for largescale testing but its ideas are relevant
14/21
RITA Functionality
Rita supports the following:
Java
program testing
Product family or single application testing
JUnit and private test execution
Full support for data flow diagrams
Visualisation and white-box coverages on four levels:
Method level: traditional coverages
Object level: object and class coverages
Package level: object coupling, reference coverages
Application level: multiple application coverages
15/21
Lessons learned from RITA
A White-Box Testing Software (WBTS) must support
traditional code
WBTS should be integrated to a software development
environment
RITA: not all applications are in product families
ASPECTS: not all applications use aspects
While stand-alone software can have similar functionality than
integrated software, usability issues favor the latter approach
Code coverage is not sufficient in WBTS
The higher is the abstraction of testing, the more complex
coverages are needed.
Even at code level code coverage gives weak results.
16/21
Aspect-Oriented Testing Tool
Based on our experiences in RITA we propose
the following requirements for an AspectOriented Testing Tool (AOTT):
It
has to support testing of traditional software
It must be integrated to a well-known and actively
updated programming environment such as Eclipse
It has to support several levels of white-box testing
including program-level, package-level, object-level,
aspect-level, and method-level
Aspect-level: testing and visualisation are inside a
single aspect.
17/21
AOTT Requirements Continue
More AOTT requirements:
It has to calculate static mesurements of the software:
Lines of code (LOC)
Aspects of code (AOC)
Coupling between objects
Depth of inheritance tree
Depth of aspect tree (aspects in aspects)
Coupling between code and aspects etc.
It has to support integration between dynamic test execution
results and static measurements
How? This is an open research question
Something else? Definitely! This is a work-in-progress list
18/21
Research directions
[Alexander, Bieman, Andrews, 2004]
Open Questions
Can we measure test coverage after weaving?
How do we test aspects that interact with the core
concern code?
inter-aspect coupling
How do we test aspects whose effects must span more
than one concern?
Are there ways to test aspects on their own?
coupling between an aspect and core concern code as a
measure of testability of the aspect
How do we test aspects that interfere with each other?
also visualisation
probably not… ?
(Can we reverse engineer the weave process?)
how does this relate to testing
19/21
Validation
How to validate that
Theory
is correct?
Application is effecient?
Alternatives:
Formalism
Empirical
controlled experiments
Practical experiments in industrial settings
All alternatives are
Relevant
Needed.
20/21
Summary
To be written...
21/21