Using Interfaces to Support the Testing of Crosscutting Features
Roberta Coelho, Arndt von Staa
Computer Science Department
An important question in the context of software product line
development is how to improve the modularization and
composition of crosscutting features. However, little attention has
been paid to the closely related issue of testing the crosscutting
features. There is still a lack of techniques to help developers test
such features. Usually, developers test the crosscutting features in
combination with the affected feature, which impairs the fault
diagnosis. This work proposes a verification approach for
crosscutting features implemented by means of aspects and
crosscutting interfaces (XPIs).
Categories and Subject Descriptors
D.2.5 [Software Engineering]: Software Testing and Debugging;
D.2.11 [Software Engineering]: Software Architecture
General Terms Verification.
Keywords aspect-oriented programming, software testing,
object-oriented frameworks, crosscutting interfaces.
Object-oriented (OO) framework technology has been widely
used in the development of software product lines as a way of
enabling systematic reuse-in-the-large. Besides their advantages,
some researchers [8, 11] have identified the inability of OO
mechanisms to address the modularization of optional and
alternative framework crosscutting features.
Crosscutting features represent concerns that are often spread over
several modules of a software system and tangled with other
features’ implementation (i.e notification and transaction
management) . Usually it is difficult to test such features
individually because there is no specific unit to be tested – these
features are spread over other features.
Aspect-oriented software development (AOSD) [7, 5] has
emerged as a technology which aims at improving the
modularization of crosscutting concerns. Recent work [2, 8, 9, 11]
has explored the use of this new paradigm to improve crosscutting
features’ modularization in product lines. While AOSD provides
an effective way for modularizing crosscutting concerns, it brings
new challenges to software testing. The new programming
constructs provided by aspect-oriented languages  are sources
for new types of programming faults .
2. Goal Statement
Our goal is to define a verification approach in order to address
the following needs of both framework and crosscutting feature
(i) Framework developers want to assure that a crosscutting
feature will not break the framework core functionalities.
(ii) Crosscutting feature developers want to verify whether the
crosscutting feature performs as expected.
The strategies that have been proposed to test aspect oriented
systems can be used (or adapted) to address the need (ii). All of
these strategies, however, are based on the obliviousness property
 which was believed to be a fundamental property for aspect
oriented programming. Sullivan et al  have proposed a new
approach to aspect-oriented design and implementation based on
the definition of crosscutting interfaces (XPI) between aspects and
classes [6, 12]. The XPIs encapsulate a set of design rules,
providing a clear specification of the interaction between aspects
and base code.
Based on the developers needs and on the recent findings on
AOSD, the following research questions have been investigated in
(i) How can we use the information embedded in XPIs between
aspects and classes in order to make the test of crosscutting
(ii) Can we add more information to such XPIs which can be
used in the testing phase of crosscutting features? Can we
use this information for test generation or to build a test
(iii)What are the framework design characteristics that improve
crosscutting feature testability? Can the developer improve
the framework design quality by testing its crosscutting
We propose a verification approach for crosscutting features
implemented by means of aspects and extension join points
(EJPs) [8, 9]. The EJP is a specialization of the XPI design
strategy to the context of framework development. According to
the EJP-based development approach [8, 9], during the framework
design a set of EJPs with their associated contracts are defined
(see Figure 1). These elements are the basis to the feature-level
testing technique and the manual and automatic inspections
techniques that comprise the verification approach proposed here.
The faults discovered in a crosscutting feature can arise from one
of the following sources: (i) bugs in the crosscutting feature logic;
(ii) inaccurate pointcut designator which intercepts a wrong set of
join points; (iii) an emergent property created by interactions
between the crosscutting features and the base code; and (iv)
faults in the core components themselves.
Copyright is held by the author/owner(s).
OOPSLA’06 October 22–26, 2006, Portland, Oregon, USA.
The proposed verification approach is composed by five steps: (1)
Inspect EJPs’ Pointcut Expressions; (2) Define EJPs’ Framework
Extension Contracts; (3) Mock each object intercepted by the
EJPs; (4) Test the Crosscutting Feature Logic; (5) Test
Crosscutting Feature Composition Behavior. Step 1 aims at
finding faults of type (ii). Step 2 aims at finding faults of types (ii)
and (iii). Step 3 implements a test infrastructure to be used in Step
4 which detects faults of type (i). Finally, Step 5 looks for bugs of
kind (iii). In order to detect faults of type (iv) traditional OO
testing techniques can be applied.
One of the hardest issues about testing a crosscutting feature is to
check whether the places where the crosscutting features apply
are correct. Since there is not a fully automatic way to detect this
kind of fault, checking all the places affected by a crosscutting
feature can be a daunting task, specially if we need to check its
negative scope (i.e check whether there is any accidental
inclusion of a point to be intercepted). In this approach in order to
detect this kind of fault the developer only needs to verify
whether the set of pointcut expressions defined inside the
framework EJPs are correct. Since, all crosscutting features only
reuse the set of pointcuts defined by EJPs, they do not need to be
inspected. If the EJPs were not used to mediate the relationship
between the core and the extension aspects, every extension
aspect would have to be inspected thus compromising the
scalability of this activity. For more details about the verification
approach the reader should refer to .
3.1 Feasibility Study
We applied the presented approach to test the crosscutting
features of a J2ME game software product line (SPL) 
implemented according the EJP-based framework development
approach. J2ME games are mainstream mobile applications of
considerable complexity . In order to apply our verification
approach, some refactorings were needed. For instance, since the
mock objects  (created in Step 3) and the real framework
objects should obey the same interface, all the elements
intercepted by the EJPs had to be defined as interfaces. As a
consequence, the EJP could remain ignorant to whether it was
intercepting the real object or the mock object during tests (see
Figure 1). A set of EJP extension contracts were defined in order
to specify the interaction constraints - between the aspects and the
framework elements - to be checked during compilation and
runtime. In order to define some contracts, however, we needed to
use very complex AspectJ constructions. We are currently
investigating simpler ways of defining interaction rules, thereby
not requiring the developer to learn complex AspectJ constructs.
Our preliminary findings  suggest that EJPs can make the test
of crosscutting features easier. However, it is still under
development. Our next steps include: (i) to define ways of
measuring the real costs and benefits of this approach; (ii) to
refine the approach by addressing the testing of different software
product lines (or families) architectures implemented using
aspects; and (iii) to develop a testing tool to support the
generation of the approach’s elements (i.e mocks, aspect unit
 R. Alexander, et al. Towards the Systematic Testing of
Aspect-Oriented Programs. Tech. Report, Computer Science,
Colorado State University, 2004.
 V. Alves, et al. Extracting and Evolving Mobile Games
Product Lines. Proceedings of SPLC'05.
 AspectJ Team:. http://eclipse.org/aspectj/.
 R. Coelho, et al. On Testing Crosscutting Features using
Extension Join Points. 3rd Workshop on Product Line
Testing (SPLiT’2006), SPLC’2006, 2006.
 R. Filman, et al. Aspect-Oriented Software Development.
 W. Griswold, et al. Modular Software Design with
Crosscutting Interfaces. IEEE Software, Special Issue on
Aspect-Oriented Programming, 2006
 G. Kiczales, et al. Aspect-Oriented Programming. Proc.
 U. Kulesza, et al. Improving Extensibility of Object-Oriented
Frameworks with Aspect-Oriented Programming, Proc of
ICSR'2006, Springer Verlag, LNCS, 2006.
 U. Kulesza, R. Coelho, V. Alves, A. Garcia, A. von Staa, C.
Lucena, P. Borba. Implementing Framework Crosscutting
Extensions with EJPs and AspectJ. Proc. of ACM SIGSoft
XX Brazilian Symposium on Software Engineering, 2006.
 T. Mackinnon, et al. EndoTesting: Unit Testing with Mock
Objects. Proc. of XP’2000, 2000.
 M. Mezini, K. Ostermann: Variability Management with
Feature-Oriented Programming and Aspects. Proc. of
FSE’2004, pp.127-136, 2004.
 K. Sullivan, et al. Information Hiding Interfaces for Aspect-
Oriented Design, Proc. of ESEC/FSE´2005, pp.166-175,
Figure 1. Crosscutting feature implementation based on EJPs.
<<uses>> re-uses aspect’s pointcuts defined in EJPs to specify an advice.
<<crosscuts>> an aspect intercept methods of an element.