A Model-Based Approach to Test Generation for
Aspect-Oriented Programs
Weifeng Xu Dianxiang Xu
Department of Computer Science Department of Computer Science
North Dakota State University North Dakota State University
Fargo, ND 58105, U.S.A Fargo, ND 58105, U.S.A
weifeng.xu@ndsu.edu dianxiang.xu@ndsu.edu
ABSTRACT classes may introduce a variety of bug hazards into the system [4].
This paper presents an approach to generating tests for adequately To name a few, improper join points, pointcuts, and advices likely
exercising interaction between aspects and classes based on lead to unexpected system behaviors or even failures. In Aspect-
aspect-oriented UML models. In this approach, an aspect-oriented Oriented Software Development (AOSD), validating whether or
model consists of class diagrams, aspect diagrams, and sequence not the aspects of crosscutting concerns are implemented correctly
diagrams. Since methods of classes and advices of aspects are is a major issue. To test an aspect-oriented system
both specified by sequence diagrams, the advices on a given implementation, it is desirable to adequately exercise classes as
method can be weaved into a new sequence diagram, which is well as aspects.
essential to the weaving mechanism in AOSD. For a woven This paper presents an approach to generating tests for adequately
sequence diagram, the approach exploits goal-directed reasoning exercising interaction between aspects and classes based on
to construct a flow graph for a given coverage criteria (e.g. the aspect-oriented UML models. In this approach, an aspect-oriented
combination of branch coverage and polymorphic coverage in this model consists of class diagrams, aspect diagrams, and sequence
paper), and further expands the graph to a flow tree, where each diagrams. Since methods of classes and advices of aspects are
path is a test. Then the approach derives objects with desired both specified by sequence diagrams, the advices on a given
states for exercising each test in the flow tree. method can be weaved into a new sequence diagram, which is
essential to the weaving mechanism in AOSD. Based on a woven
Categories and Subject Descriptors sequence diagram, the approach exploits goal-directed reasoning
D.2.5 [Software Engineering]: Testing and Debugging - Testing to construct a flow graph for a given coverage criteria (e.g. the
tools (e.g., data generators, coverage testing) combination of branch coverage and polymorphic coverage in this
paper), and further expands the graph to a flow tree, where each
General Terms path is a test. Then the approach derives objects with desired
Algorithms, Design, Languages states for exercising each test in the flow tree.
The rest of the paper is organized as follows. Section 2 briefly
Keywords reviews related work on testing aspect-oriented programs. In
Aspect-oriented programming, testing, UML, sequence diagram,
section 3, we introduce UML-based aspect-oriented modeling. In
test generation.
section 4, we present how to generate test cases. Section 5
1. INTRODUCTION concludes the paper.
An aspect-oriented program typically consists of a number of
modules (or classes) and aspects that can be woven into an
2. RELATED WORK
AOSD as an emerging paradigm of software development is still
executable whole [1][2][3]. The crosscutting mechanism of
in its infancy. It is not surprising to see that little research on
aspects frees the programmer from interweaving different
testing aspect-oriented programs has been published [4].
concerns (i.e. goals, concepts, or areas of interests) in a
monotonous program hierarchy imposed by the base language. Zhao has proposed a data flow based approach to unit testing of
This greatly facilitates identifying and modularizing separate aspect-oriented programs [10]. For each aspect or class, the
concerns that crosscut multiple functional components or objects. approach performs three levels of testing, i.e., intra-module, inter-
The dynamic behavior of objects, including interactions, module, and intra-aspect/intra-class testing. Definition-Use pairs
dependencies, and constraints on the message sequences, is (DU-pairs) are constructed to determine what interactions
therefore determined collectively by the specification of both between aspects and classes must be tested. Zhao and Rinard [11]
objects (classes) and aspects. The interaction between aspects and have also exploited system dependence graphs to capture the
additional structures in aspect-oriented features such as join
points, advice, aspects, and interactions between aspects and
Permission to make digital or hard copies of all or part of this work for classes. In this approach, control flow graphs are constructed at
personal or classroom use is granted without fee provided that copies are both system and module level, and test suites are derived from
not made or distributed for profit or commercial advantage and that control flow graphs. No fault model is targeted to help detect most
copies bear this notice and the full citation on the first page. To copy likely faults.
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee. Alexander, Bieman, and Andrews [4] have recently proposed a
Submission to AOSD’05 Workshop on Testing AOP. fault model for aspect-oriented programming, which includes six
Copyright XXXX XXX X-XXXXX-XXX-X/XX/XXXX…$X.00. types of faults: incorrect strength in pointcut patterns, incorrect
1
, aspect precedence, failure to establish postconditions, failure to join points because a preceding link does represent two or three
preserve state invariants, incorrect focus of control flow, and join points. Fig. 3 illustrates two types of join points, i.e. method
incorrect changes in control dependencies. While this fault model call and method execution. A message m(x), denoted by a link,
has not yet constituted a fully-developed testing approach, it is represents both types. The call designator is used when one is
undoubtedly useful for developing testing tools and determining interested in the actual calling of the method or constructor as
coverage strategies and criteria. opposed to the execution of code within a join point. The duration
Ubayashi and Tamai [12] have proposed a model checking when a control passes through these join points are denoted as
method for verifying whether or not an aspect-oriented program dotted rectangles. In the example, left rectangle indicates the
satisfies expected properties. A similar method is presented by method call duration, and the right rectangle indicates the duration
Denaro and Monga [13]. This work primarily concerns with the of method execution. Solid diamonds are used to distinguish
properties of concurrence, such as deadlock, liveness, and different type of advices access points. The diamond attached to
fairness. Li, Krishnamurthi and Fisler’s three-valued model the top of the rectangle is denoted as a before type access point,
checking approach allows for reasoning about interactions as the and the diamond located at the bottom of the rectangle indicates
result of weaving [14]. Different from verification, Sereni and the access point of after type. The solid circle at the top of the
Moor [15] have proposed a method for static analysis of aspects rectangle is the around type access point, and it should be placed
based on a syntactic model of pointcut designators using regular after before type. To represent around advices, a pseudo control
expressions. object around is introduced to play a role of delegation.
To reduce the cost of testing aspects, Zhou, Richardson and Ziv Class A Class B
[25] have recently introduced a control flow based approach to
selecting relevant test cases for testing aspects. A tool has been port port
developed to calculate test coverage and select relevant test case if
new test cases should be developed when reused test cases can not
cover the aspects under test satisfactorily. Connector
It is worth mentioning that aspects can provide a convenient way
to develop testing tools or built-in tests [16], although the work <<aspect>>
along this line is in essence irrelevant to the paper. Nevertheless, pointcut
testing such aspects is also a critical issue. advice
3. ASPECT-ORIENTED MODELING Figure 1. Aspectual class diagram
Based on the work [17][18][19] [20], we extend UML for aspect-
oriented modeling. Our goal is to allow aspect-oriented models to Rental Movie
carry structural and behavioral information that is necessary for
movie:Movie title: String
test automation. daysRented:int price: Price
As an extension to UML class diagrams, an aspectual class Rental(Movie,int) Movie (string,Price)
diagram represents a collection of declarative (static) model getCharge ():double getPrice ():Price
elements, such as classes, aspects, types, and their contents and getDaysRented ():string setPrice ()
getMovie():Movie getTitle ():string
relationships. Using AspectJ meta model [21], crosscutting setTitle()
concerns can be expressed in Fig. 1, where each aspect has two
components: pointcut and advice. Port is a structural feature of a <<Join point>>
classifier that specifies a distinct interaction point between that <<Join point>>
dsysRented:Field get
classifier and its environment or between the classifier and its
internal parts. Connector specifies a group of links that enables price:Field get
<<aspect>>
communication between two or more instances. A port represents AccessControl
a join point and a connector represents a pointcut expression.
Fig. 2 shows an aspectual class diagram with two classes: Rental <<advice>>
<after> <<pointcutExp >>
and Movie. Each class has a join point collected in pointcut fieldAccess
expression fieldAccess. filedAccess, encapsulated in aspect get(int
AccessControl, facilitates communication between Rental and <<pointcut>> Rental.daysOfRented)
fieldAccess || get(Price
Movie objects. Movie.price)
We use sequence diagrams to model interaction between objects,
including both class methods and aspect advices. Since sequence
diagrams capture messages flows, they facilitate weaving aspects
into classes. In the following, we introduce some additional
Figure 2 MovieRental aspectual diagram
notation for the weaving, upon which the test generation approach
is built. Take Fig. 4 as an example. The sequence diagram, describing the
behavior of getCharge, consists of three objects, Rental, Movie
In sequence diagrams, we represent join points as links. Field
and Price, and five messages, getPrice, getPregisteredPrice,
references or field assignments are stereotyped as “pseudo”
getPeriod, getDiscountedPrice, chargeWithinPeriod and
invocations of “pseudo” operations, such as get() and set(), as in
chargeBeyondPeriod. The basic business rules for calculating the
[22]. There are no links to represent execution and initialization
total charge are as follows: 1) All the movies have been
2
