Modular Construction of Context-Speciﬁc Test Case Migration Methods

Ivan Jovanovikj

, Enes Yigitbas

, Marvin Grieger

, Stefan Sauer

and Gregor Engels

Software Innovation Lab, Paderborn University, Paderborn, Germany

VHV Gruppe, Hannover, Germany

Keywords:

Test Case Migration, Software Co-evolution, Software Reengineering, Method Engineering.

Abstract:

Migration of test cases has a twofold beneﬁt in software migration projects: reuse of valuable knowledge as

well as time and cost savings. The diversity of software migration project contexts require a ﬂexible and mod-

ular construction method to address several aspects like different system and test environments or the impact

of the system changes on the test cases. When an inappropriate migration method is used, it may increase

the effort and the costs and also decrease the overall software quality. Therefore, a critical task in test case

migration is to provide a transformation method which ﬁts the context. To address this problem, in this paper,

we present a framework that enables a modular construction of context-speciﬁc migration methods for test

cases by assembling predeﬁned building blocks. Our approach builds upon an existing framework for modular

construction of software transformation methods and consists of a method base and a method engineering

process. Method fragments are the atomic building blocks of a migration method, whereas method patterns

encode speciﬁc migration strategies. The guidance on development and enactment of migration methods is

provided by the method engineering process. We evaluate our approach in an industrial case study where a

part of the Eclipse Modeling Framework was migrated from Java to C#.

1 INTRODUCTION

Software testing plays an important role in software

migration as it veriﬁes whether the migrated system

still provides the same functionality as the original

system which is the main requirement in a software

migration (Bisbal et al., 1999). Since software migra-

tion is established to reuse existing systems, we want

to reuse test cases as well. The reuse of test cases can

be beneﬁcial, not just from economical perspective,

but also from practical perspective: the existing test

cases contain valuable information about the func-

tionality of the source system and therefore, about the

functionality of the migrated system, too. A migra-

tion, in general, is performed by development and en-

actment of a migration method. A migration method,

or a transformation method in a broader sense, deﬁnes

which activities should be performed, which tools to

be applied, and what artifacts should be generated in

order to transfer a system from one environment to

another. The same applies for the test case migration

methods.

Having the right migration method and enacting

it, is very important because a non-suitable migration

method may lead to more complex and more expen-

sive migration. Another aspect is the dependency be-

tween the system and the test cases. Since the test

cases are coupled with the system they are testing,

the system changes need to be detected, understood

and then reﬂected on the test cases to facilitate reuse.

In other words, the test cases need to be co-evolved.

However, co-evolving test cases is far from being triv-

ial since several challenges need to be addressed (Jo-

vanovikj et al., 2016a), like quality assessment, refac-

toring or reﬂection of system changes. For this rea-

son, we need a method which is capable of capturing

such information, and accordingly enabling the devel-

opment of a suitable test case migration method.

We address the aforementioned issues by pro-

viding a framework for modular construction of

context-speciﬁc test case migration methods. Our ap-

proach is highly inﬂuenced by the MEFiSTO Frame-

work (Grieger et al., 2016), as this approach pro-

vides high degree of controlled ﬂexibility. We ex-

tend this framework by considering the test cases as

well, thus enabling development of test case migra-

tion methods which enable automated co-evolution

of test cases for a speciﬁc migration context. As

shown in Figure 1, the solution approach consists of a

Method Base and a Method Engineering Process. The

Method Base contains the building blocks needed for

assembling of the migration method, namely Method

534

Jovanovikj, I., Yigitbas, E., Grieger, M., Sauer, S. and Engels, G.

Modular Construction of Context-Speciﬁc Test Case Migration Methods.

DOI: 10.5220/0007690205340541

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 534-541

ISBN: 978-989-758-358-2

Method Development

Method Enactment

Context Characterization

Transformation Method Construction

Tool Implementation

Transformation

Method Base

Method Fragments

Method Patterns

Model of

Abstract

Tests

Test

Code

Restucturing

Test Case

Understanding

Original

Test

Code

Original

Source

Code

System

Migration

Parser

M2M

Code

Generator

Original

Test

Code

Migrated

Test

Code

Test Code

Model

Test

Model

Migrated

Test Model

Mig. Test

Code Model

M2M

Parser

Code

Generator

Context

Model

Context-Speciﬁc

Migration Method

Speciﬁcation

Original

Test Code

Context-

Speciﬁc

Tool Chain

M2M

Parser

Migrated

Test Code

uses

Figure 1: Approach Overview.

Fragments and Method Patterns. A Method Fragment

is an atomic building block of a migration method,

whereas a Method Pattern represents a strategy and

indicates which fragments are necessary and how to

assemble them together. Having the Method Frag-

ments and Method Patterns, a guidance is needed on

how to create a migration method for a speciﬁc con-

text. This is done by the Method Engineering Process,

which guides the development and the enactment of

the context-speciﬁc migration method.

The structure of the rest of the paper is as fol-

lows: In section 2, we introduce the content of the

Method Base. Then, in section 3, we present the

Method Engineering Process, which is instantiated in

section 4 based on a case study from an industrial con-

text. In section 5, we discuss the related work and at

the end, in section 6 we conclude our paper and give

an outlook on future work.

2 METHOD BASE

The Method Base contains the knowledge of the avail-

able migration strategies. It is actually a repository

containing reusable building blocks of methods and

includes method fragments and method patterns. In

the following, we present an excerpt of the method

fragments and patterns.

2.1 Method Fragments

A method fragment is an atomic building block of a

migration method, i.e., an activity, artifact or tool. As

we follow the idea of model-driven software migra-

tion (Fuhr et al., 2012), our method fragments belong

to one of the following reengineering processes: Re-

verse Engineering, Restructuring, and Forward Engi-

neering (Chikofsky and Cross, 1990). The activities

as well as the artifacts are represented in Figure 2 as

an instance of the well-known horseshoe model (Kaz-

man et al., 1998).

Artifacts are constituting parts of each migration

method and are distinguished by the level of abstrac-

tion they are belonging to. On the System Layer, tex-

tual artifacts representing test code and models of the

test code are placed. Regarding the textual artifacts,

this is either the Original Test Code or the Migrated

Test Code. The test code can be either the test cases,

implemented in a speciﬁc testing framework, e.g. jU-

nit

or MSUnit

, test conﬁguration scripts or a man-

ually implemented additional test framework.

Similarly, regarding the models of the code it is ei-

ther the Model of Original Test Code or the Model of

the Migrated Test Code. The Model of the Test Code

http://junit.org/junit4/

https://msdn.microsoft.com/en-

us/library/ms243147.aspx

Modular Construction of Context-Speciﬁc Test Case Migration Methods

535

System Layer

Platform-Independent

Layer

Exogenous Model

Transformation

Text-to-Text

Transformation

Activity Speciﬁcation

Migrated

Test

Code

Language

Transformation

Text-to-Model /

Model-to-Text

Transformation

Original

Test

Code

Model of the

Original

Test Code

Model of the

Original

Executable Tests

Model of

Abstract Tests

Platform-Sepciﬁc

Layer

System

Behavior

Model

Model of the

Migrated

Test Code

Model of the

Migrated

Executable Tests

Reimplementation

Framework

Transformation

Test Case

Understanding

Test

Concretiztaion

Test Code

Generation

Model

Discovery

Test

Abstraction

Test

Concretiztaion

System Behavior

Recovery

Abstract Test

Derivation

Removal

No Transformation

Endogenous Model

Transformation

Enrichment

Restucturing

Test DesignTest Implementation

Model

Code

Artifact Speciﬁcation

Tool Speciﬁcation

Tool

Model

Transformation

Engine

Code

Generator

Parser

Direct

Test Code

Generation

Direct

Test Code

Understanding

Figure 2: Excerpt of Method Fragments stored in the Method Base.

represents the test code in a form of an Abstract Syn-

tax Tree (OMG, 2011) of the appropriate language of

the original or the target environment.

The Platform-Speciﬁc Layer is a higher level of

abstraction compared to the system layer. Here,

technology-speciﬁc concepts are used to represent the

test cases for both the source and the target environ-

ment. Model of Original/Target Executable Tests is

considered as platform-speciﬁc as it represents the ex-

ecutable test cases by using testing concepts which

are speciﬁc for a particular testing framework, i.e., by

using meta-models of jUnit or MSUnit to model the

test code.

On the Platform-Independent Layer the models

representing the test cases are independent of any par-

ticular testing framework or testing technology. On

this level of abstraction, we distinguish between two

types of models, the Model of the Abstract Tests and

the System Behavior Model. The Model of the Ab-

stract Tests is considered to be platform-independent

as it is independent of any concrete testing frame-

work. Standardized languages like UML Testing Pro-

ﬁle (UTP) (OMG, 2013) and Test Description Lan-

guage (TDL) (ETSI, 2016) are used for modeling the

abstract tests. On the highest level of abstraction, we

foresee the System Behavior Model that represents a

compact representation of the expected behavior of

the system. Behavioral diagrams like the UML ac-

tivity or sequence diagram, or state machines can be

used to represent the expected behavior of the system.

Activities in the test case reengineering horseshoe

model produce or consume appropriate artifacts. As

can be seen in Figure 2, these activities can be distin-

guished by the reengineering process they belong to,

namely Reverse Engineering, Restructuring, or For-

ward Engineering.

Reverse Engineering, as deﬁned in (Chikofsky

and Cross, 1990), is the process of analyzing a sub-

ject system to create representations of the system in

another form or on a higher level of abstraction. Ap-

plied in the software testing domain, it is a process of

analyzing a test case and creating another represen-

tation of them on a higher level of abstraction, e.g.,

by using test models. In general, reverse engineer-

ing can be seen as combination of Model Discovery

and Model Understanding (Bruneliere et al., 2010).

The Model Discovery step relies on syntactical anal-

ysis and by using a parser it allows automatic text-

to-model transformation to create a model of the test

case source code represented as an Abstract Syntax

Tree (AST) (OMG, 2011). Model Understanding, in

general, is a model-to-model transformation activity,

or a chain of such activities, which takes the initial

models, applies semantic mappings and generates de-

rived models on a higher level of abstraction. Here,

we distinguish three sub-activities: Firstly, the ini-

tial models are explored by navigating through their

structure in an activity called Test Case Understand-

ing. Model elements which represent test relevant

concepts like test suite, test case or assertion are iden-

tiﬁed and then, by applying a model-to-model trans-

formation, a test model of executable test cases is

obtained which is platform speciﬁc and it is an in-

stance of a metamodel of a particular testing frame-

work (e.g., jUnit, MSUnit or TTCN-3). By apply-

ing the Test Abstraction activity, which is a model-

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

536

to-model transformation as well, one can obtain a

model of the abstract test cases which is platform-

independent. The System Behavior Recovery activity

is applied in order to obtain the highest possible level

of abstraction deﬁned by our reengineering model.

According to (Chikofsky and Cross, 1990), Re-

structuring is ”the transformation from one represen-

tation form to another at the same relative abstraction

level, while preserving the subject system’s external

behavior (functionality and semantics)”. In the test-

ing domain, we deﬁne test restructuring as the trans-

formation from one test representation to another at

the same relative abstraction level, while preserving

the ”semantics” of the tests. Here, with ”semantics”

we mean the functionality that is being checked by a

particular test. This activity has been foreseen on both

the System Behavior Model and the Model of Abstract

Test. The Restructuring activity is of course inﬂu-

enced by the target testing environment, testing tool,

or by requirements on improving the quality of the

test cases (e.g., maintainability). However, it could

also be inﬂuenced by the changes that happen in the

system migration. Since these changes may be rele-

vant for the test models, they have to be reﬂected on

the tests as well.

As deﬁned by (Chikofsky and Cross, 1990),

Forward Engineering is ”the traditional process of

moving from high-level abstractions and logical,

implementation-independent designs to the physical

implementation of a system”. In the ﬁeld of soft-

ware testing, this can be paraphrased as a process

of moving of high-level test abstractions and logi-

cal implementation-independent design to the phys-

ical implementation of the test cases. The test models

are used as input for a chain of model-to-model trans-

formations, ending with a model-to-text transforma-

tion, which provides the test code as output. Abstract

Test Derivation takes as input the System Behavior

Model and produces Model of Abstract Test Cases, a

platform-independent model of the test cases. Then,

by applying Test Concretization a Model of Migrated

Executable Test Cases is obtained. This model is al-

ready speciﬁc for a particular testing framework and

can be used for the generation of the Test Code by

executing the Test Code Generation activity, which is

a model-to-text transformation. Since test cases are

generated from the test model, this can be seen as e

typical model-based testing activity (Jovanovikj et al.,

2016b). The tools which support forward engineering

are known as generators and for each speciﬁc target

platform, an appropriate generator is needed. Custom

code generators can be built by using Xtend

which

is a statically typed programming language which of-

http://www.eclipse.org/xtend/

fers features like template expressions and intelligent

space management. The Reimplementation is a text-

to-text transformation which is performed manually

The Language Transformation also known as AST-

based transformation (Kazman et al., 1998), deﬁnes

a direct mapping between the Original Model of the

Test Code and the Migrated Model of the Test Code.

The Framework Transformation, on the other hand,

deﬁnes a mapping directly between two testing frame-

works. The Enrichment activity is applicable to vari-

ous models, e.g., Original Model of Executable Tests,

Model of Abstract Tests, or System Behavior Model.

The Removal activity is used to specify which part of

the test case code should not be transformed.

In order to support the previously introduced ac-

tivities, thus enabling a (semi-)automatic transforma-

tion, we foresee in total three types of tools that are

needed. Firstly, a Parser is needed to obtain the ini-

tial models out of the textual artifacts, i.e, to perform

the Model Discovery activity. Then, in a series of

model-to-model transformations, which are speciﬁed

by transformation rules, initial models are obtained.

The speciﬁed rules are then executed by an Model

Transformation Engine. Finally, a Code Generator

is needed to perform the model-to-text transforma-

tion by executing the test code generation rules pre-

viously speciﬁed, thus generating the test code for the

migrated test cases.

2.2 Method Patterns

Having only method fragments like artifacts, activi-

ties or tools is not sufﬁcient as no guidance is pro-

vided how to assemble them and thus create a test case

migration method. For this purpose, we additionally

provide method patterns.

A method pattern, intuitively, represents construc-

tion guidelines for migration methods and follows

a certain strategy. It contains the methodological

knowledge with the purpose to address the problem

associated to it. Technically seen, a method pat-

tern deﬁnes which method fragments should be cus-

tomized and how to put them together. Functionality

preservation is a main requirement in any migration

project, and therefore, in test case migration too (Bis-

bal et al., 1999). To preserve this functionality, a

consistent path in the horseshoe model has to be re-

alized from the Original Test Code to the Migrated

Test Code. In the following, as shown in Figure 3,

we present an excerpt of the method patterns that pre-

serve functionality. Furthermore, we have also ob-

served architectural restructuring pattern, which pro-

vide a methodological solution to make a architectural

changes in the test cases during their migration. Due

to space constraints, we only discuss the former cate-

Modular Construction of Context-Speciﬁc Test Case Migration Methods

537

gory of migration method patterns.

The Language-based Test Transformation pattern

deﬁnes the migration of the functionality of the test

cases by deﬁning a mapping between the language

constructs in both original and target environment.

The mapping is applied by a direct transformation be-

tween the Model of the Original Test Code and the

Model of the Migrated Test Code. Theoretically seen,

this pattern could be applied actually in any migra-

tion scenario, but its suitability mainly depends on

the complexity of the model transformations between

both models. Firstly, the extracted Model of the Orig-

inal Test Code needs to be interpreted to identify the

test concepts to be transformed. Then, it could be

necessary to restructure the explicit test concepts, like

test behavior or test assertions. Once prepared, the

test concepts on the original environment have to be

mapped to the test concepts of the target environment.

Thus, this pattern could be considered suitable if the

effort of test interpretation and restructuring is rela-

tively low. However, from test perspective, it basi-

cally means, the transformation of the test concepts

have to be done implicitly.

The Framework-based Test Transformation pat-

tern deﬁnes to migrate the functionality of the test

cases by using an intermediate test representation

on platform-speciﬁc layer. The testing concepts to-

gether with the test data are explicitly represented by a

Model of Original Executable Tests. By applying the

separation of concerns principle, this pattern makes

the transformation step less complex compared to the

Language-based Test Transformation. Namely, the

ﬁrst concern of interpretation, is explicitly addressed

by the Test Case Understanding activity. Then, the

Restructuring could be applied on the Model of Orig-

inal Executable Tests, which enables direct manipu-

lation of the test concepts, e.g. test assertions. After

Restructuring, the mapping to the target test frame-

work, i.e., mapping to the Model of Migrated Exe-

cutable Tests is performed. Finally, Direct Test Code

Generation is applied either directly or via Test Con-

cretization and Model of the Migrated Test Code, the

Migrated Test Code is generated. This pattern could

be considered suitable when the difference of the test

case implementation is signiﬁcantly different in the

original and the target testing frameworks. Compared

to the Language-based Test Transformation pattern,

this pattern enables direct, i.e., explicit representation

and manipulation of test constructs.

The Conceptual Test Transformation pattern de-

ﬁnes to migrate the test functionality by using an in-

termediate representation in terms of a Model of Ab-

stract Tests on a platform-independent layer. This

improves the dependent framework transformation on

Framework-based

Test Transformation

Language-based

Test Transformation

Reimplementation

Test Code Removal

Conceptual

Test Transformation

No Activity

Test

Code

Model

Manual

Activity

Automated

Activity

Figure 3: Excerpt of basic method patterns.

the platform-speciﬁc layer by explicitly representing

some test concepts on a higher level of abstraction

as part of the Model of Abstract Tests. For example,

from the test design perspective, the test architecture

or test behavior could be explicitly represented with

this model. This pattern could be considered suitable

when some test concepts are realized completely dif-

ferent in both environments or when a restructuring of

the test architecture or test data is necessary.

The Reimplementation pattern deﬁnes to migrate

the test functionality by having it manually trans-

formed by software developers. The main task is to

implement the same test cases, testing the same func-

tionality in the target environment. This pattern could

be suitable in cases when an automatic migration is

difﬁcult to be implemented. The Test Code Removal

pattern deﬁnes not to migrate certain part of the test

code, i.e., no transformation should be performed on

it. For example, it could be that some parts of the

original system are now implicitly supported in the

new environment, e.g., by a library or a framework,

so there is no longer need to be tested.

3 METHOD ENGINEERING

PROCESS

The method engineering process describes the main

activities to be followed in order to create a context-

speciﬁc test case migration method as well as their

relation to the method base. As already shown in

Figure 1, the activities are split in two main disci-

plines: Method Development and Method Enactment.

The essential process input is the Original Test Code,

which gets transformed to Migrated Test Code once

the process is being enacted. The Migrated Test Code

represents the test cases which can be run in the tar-

get environment and validate the system migration.

The activities of both disciplines are associated with

a ﬂow that is attached with a Context-Speciﬁc Migra-

tion Method Speciﬁcation which describes the actual

migration method.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

538

3.1 Method Development

By performing activities of the Method Development

discipline a context speciﬁc method gets developed.

The main activities are Context Characterization and

Transformation Method Construction.

The ﬁrst activity is the Context Characterization,

in which the migration context is analyzed and char-

acterized, from both system migration and testing per-

spective. Furthermore, impact analysis is also per-

formed to identify the impact that the system changes

have on the test cases. The gathered knowledge about

the migration context is required in order to develop a

suitable test case migration method. In order to struc-

ture the context information, we developed a migra-

tion context model, whose excerpt is shown in Fig-

ure 4. It mainly contains the technical background

of the migration context, i.e., the characteristics of

the source environment of the system and the test

cases, the target system environment, and the desired

test target environment. Last but not least, the sys-

tem transformation characteristics are also analyzed

as they are of great importance to understand their im-

pact on the test cases. For example, the kind of sys-

tem transformation or the target testing environment

are important context characteristics which should be

considered. Another purpose of the this activity is to

perform an initial assessment of the method patterns

against a set of inﬂuence factors. On the basis of in-

formation in the obtained context model a set of in-

ﬂuence factors are set. Then, each pattern is analyzed

against each identiﬁed inﬂuence factor, which in turn

could have either positive or negative inﬂuence on the

selection of a particular pattern.

Having the context information collected, the

Transformation Method Construction activity can be

initiated. In this activity, on the basis of the previously

identiﬁed context information, a context-speciﬁc mi-

gration method gets constructed. First of all, a suit-

able pattern is selected, which in turn means a de-

cision how to transform the test cases. Once a pat-

tern is selected, then it has to be conﬁgured, i.e., a

set of method fragments has to be instantiated. Then,

the instantiated fragments are customized regarding

the functionality they are transforming. Customiza-

tion of fragments means specifying them at a level of

details so that it provides guidance during the enact-

Source

Environment

Characteristics

System Migration

Context Factor

Migration

Context

Factor

Testing Migration

Context Factor

Target

Environment

Characteristics

Transformation

Characteristics

Source

Environment

Characteristics

Target

Environment

Characteristics

Figure 4: An Excerpt of the Context Model.

ment. The outcome, the Context-Speciﬁc Migration

Method Speciﬁcation, deﬁnes how to do the migra-

tion by deﬁning the activities to be performed and the

artifacts that should be generated.

3.2 Method Enactment

During Method Enactment the context-speciﬁc tools

are developed that are required for the automation of

the migration method or part of it. Thereafter, the mi-

gration method is performed as deﬁned in the migra-

tion method speciﬁcation.

Having the migration method speciﬁed, every

speciﬁed activity that shall either be performed auto-

matically or semi-automatically, an appropriate tool

is implemented. In general, there are two different

types of tools: tools which are used in any migration

method and speciﬁcally developed tools for a certain

method. For example, if a given migration method

deﬁnes a transformation which should be automated,

then a model transformation engine that can execute

model transformation rules is required. If, on the

other hand, a migration method, i.e., a given method

fragment requires a speciﬁc tool, e.g., a semantic an-

alyzer, then it should be speciﬁcally developed. In

general, the Tool Implementation activity requires a

knowledge for model-driven engineering and devel-

opment of reengineering tools. As a result of this ac-

tivity, an integrated tool chain is delivered. During

the last activity of the process, named as Transfor-

mation, the actual transformation of the original test

cases occurs. This activity encompasses the enact-

ment of the previously developed migration method

and the corresponding tool chain. By enacting the mi-

gration method, the source test cases are being trans-

formed, i.e., migrated to the new environment and can

be used to validate the system migration.

4 CASE STUDY

Our method was applied in an industrial project where

the main goal was to migrate parts of the well known

Eclipse Modeling Framework (EMF) along with the

Object Constraint Language (OCL) from Java to C#

( Figure 5). As EMF and OCL are stable and well-

tested and all test cases are available on public code

repositories, our goal was to reuse the OCL test cases

in order to validate the OCL functionality in the tar-

get environment. The main change implemented by

the system migration, besides switching from Java to

C#, was to change from a Just-In-Time (JIT) compi-

lation in the old system to an Ahead-Of-Time (AOT)

compilation of OCL constraints in the migrated sys-

tem. The test cases which have similar structure

Modular Construction of Context-Speciﬁc Test Case Migration Methods

539

are selected for automated migration. For those test

cases where it is difﬁcult to identify some repeating

structure, reimplementation is a more suitable solu-

tion. Additionally, an interlayer testing framework

TestOCL exists in order to simplify the test cases.

It provides domain-speciﬁc assert functions for the

OCL domain, e.g., assertQueryTrue. Regarding

the language, the source system is implemented in

Java under Java Platform. Regarding the architec-

ture, OCL is implemented in that a native OCL ex-

pressions are speciﬁed and using the JAVA API they

are evaluated. The language in the target environment

is C# under the .net platform. The OCL functional-

ities are implemented directly in the corresponding

classes that are speciﬁed in the migrated system. Re-

garding the system transformation characteristics, the

activities are ranging from manual to completely au-

tomatic. Those transformations that were performed

automatically, have been formalized using transfor-

mation rules speciﬁed in Java. The process of trans-

formation was supported by implementing transfor-

mation rules based on Xtend. At highest importance

for the reﬂection of the changes to the test cases are

the transformation rules speciﬁed for the transforma-

tion of OCL expression to C#. The source test envi-

ronment is JUnit, with an additional interlayer exten-

sion, the TestOCL. The test cases are unit level test

cases, separated in different test suites according the

functionality they are addressing. The anatomy of the

test cases in the target environment is that a single

test case may contain multiple assertions, normally

speciﬁed using the assert functions provided by the

TestOCL extension. The target environment language,

in this particular case C#, implies usage of MSUnit.

To automate the test case migration, two Eclipse

plug-ins were developed to automate the reengineer-

ing activites. The overall result was an automated mi-

Test

Code

(C#)

Test

Code

(Java)

Model of the

Test Code

(Java AST)

Model of the

Executable

Tests

(xUnit)

Model of the

Executable

Tests

(MSUnit)

Reimplementation

Framework

Transformation

Test Case

Understanding

Test Code

Generation

Model

Discovery

Java

Parser

Java

AST

Java2

Xunit

Xunit2

MSUnit

xUnit

MSUnit

Model

Textual Artefact

Artifact

Speciﬁcation

Exogenous

Model

Transformation

Text-to-Text

Transformation

Activity

Speciﬁcation

Text-to-Model /

Model-to-Text

Transformation

Tool

Speciﬁcation

T2M/M2M/M2T

Meta-Model

Figure 5: Excerpt of the Test Case Migration Method Spec-

iﬁcation.

gration of over 92% of 4000 existing jUnit test cases.

8% of the test cases (mainly regression test) were not

migrated automatically, due to the irregular structure

which complicates an automation.

5 RELATED WORK

There are already several approaches that implement

the forward engineering process of test case reengi-

neering activities. The beneﬁt from the separation of

PIMs and PSMs in the generation and execution of

tests is presented in (Heckel and Lohmann, 2003). A

model-driven testing methodology which transforms

UML system models to test-speciﬁc UML Testing

Proﬁle models is proposed in (Dai and Dai, 2004).

There are also appraoches that present reverse engi-

neering activities for test cases. In (Hungar et al.,

2003), test models are extracted out of test cases by

means of automata learning. The beneﬁt of reusing

test cases has been detected in a lot of software migra-

tion projects. In the SOAMIG (Zillmann et al., 2011)

migration project, existing test cases are used for the

analysis of the legacy system. MoDisco (Bruneliere

et al., 2010), on the other hand, is a generic and ex-

tensible framework which follows the principles of

Model-Driven Reverse Engineering. However, mi-

gration of test cases is still not addressed by this

framework. The ARTIST (Menychtas and Al., 2014)

project is the most interesting project as they also ad-

vocate migration of the test cases in a model-driven

way, i.e., in a similar way the system has been mi-

grated, thus reusing, above all, the developed tools.

Our work differs in that way, that we propose a mod-

ular construction of migration methods, by consider-

ing the migration context and also by addressing the

co-evolution issue.

Regarding method engineering, depending on the

degree of controlled ﬂexibility, there are different cat-

egories of method engineering approaches, namely

those that provides ﬁxed methods, a selection out

of set of ﬁxed methods, conﬁguration of a method,

tailoring a method or a modular construction of the

method. The method tailoring approaches enable tai-

loring of a provided method which can be changed

arbitrarily. The problem is however, that the pro-

cess of changing of the provided method is not guided

by a method engineering process. The following ap-

proaches follow this strategy: REMICS(Mohagheghi,

2010), SOAMIG (Zillmann et al., 2011), Reference

Migration Process (ReMiP) (Sneed et al., 2010), and

ARTIST (Menychtas and Al., 2014). The approaches

that provide modular construction of a method rely on

a set of predeﬁned building blocks for methods and a

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

540

method engineering process that guides the method

construction. (Khadka et al., 2011) is a method engi-

neering approach that enables modular construction,

but is specialized for migration to service-oriented

environments. The MEFiSTO Framework (Grieger

et al., 2016) overcomes this issue by providing a gen-

eral solution for modular construction of situation-

speciﬁc migration methods. However, it lacks the

support for migration of test cases, namely the con-

sideration of the test context, as well as the analysis

of the impact that the system changes have on the test

cases.

6 CONCLUSION AND FUTURE

WORK

We presented a framework that enables a modular

construction of context-speciﬁc, model-driven migra-

tion methods for test cases. The framework con-

sists of a method base and a method engineering pro-

cess. The method base contains method fragments,

as atomic building blocks of a migration method,

and method patterns which encode speciﬁc migration

strategies. The method engineering process provides

a guidance on development and enactment of migra-

tion methods. We applied our framework in an in-

dustrial project in which a migration of part of EMF

from Java to C# was performed. Using this approach,

a model-driven test case migration method was de-

veloped and enacted and as a result, 4000 unit test

cases were migrated from one environment to another,

most of them completely automatic. As future work

we plan to extend our framework by adding a post-

migration phase, in which the validity of the test case

migration is being assessed. This validation phase

should check whether the functionality of the tests is

preserved, i.e., whether the tests after migration are

still testing the same part of the system functionality.

REFERENCES

Bisbal, J., Lawless, D., Bing Wu, B., and Grimson, J.

(1999). Legacy information systems: issues and di-

rections. IEEE Software.

Bruneliere, H., Cabot, J., Jouault, F., and Madiot, F. (2010).

MoDisco. In Proceedings of the IEEE/ACM interna-

tional conference on Automated software engineering

- ASE ’10. ACM Press.

Chikofsky, E. J. and Cross, J. H. (1990). Reverse Engi-

neering and Design Recovery: A Taxonomy. IEEE

Software.

Dai, Z. R. and Dai, Z. R. (2004). Model-Driven Testing

with UML 2.0. Computing Laboratory, University of

Kent.

ETSI, E. T. S. I. (2016). ETSI ES 203 119–1: Methods for

Testing and Speciﬁcation (MTS); The Test Descrip-

tion Language (TDL); Part 1: Abstract Syntax and

Associated Semantics, v1.3.1.

Fuhr, A., Winter, A., Erdmenger, U., Horn, T., Kaiser,

U., Riediger, V., and Teppe, W. (2012). Model-

Driven Software Migration - Process Model, Tool

Support and Application. In Migrating Legacy Appli-

cations: Challenges in Service Oriented Architecture

and Cloud Computing Environments. IGI Global.

Grieger, M., Fazal-Baqaie, M., Engels, G., and Klenke,

M. (2016). Concept-based engineering of situation-

speciﬁc migration methods. In Proceedings of the

15th International Conference on Software Reuse:

Bridging with Social-Awareness.

Heckel, R. and Lohmann, M. (2003). Towards model-driven

testing. In Electronic Notes in Theoretical Computer

Science. Elsevier.

Hungar, H., Hungar, H., Margaria, T., and Steffen, B.

(2003). Test-Based Model Generation for Legacy Sys-

tems. IEEE International Test Conference.

Jovanovikj, I., Grieger, M., and Yigitbas, E. (2016a). To-

wards a model-driven method for reusing test cases in

software migration projects. Softwaretechnik-Trends.

Jovanovikj, I., G

uldali, B., and Grieger, M. (2016b). To-

wards applying model-based testing in test case mi-

gration. Softwaretechnik-Trends, Proceedings of the

39th Workshop Test, Analyse und Veriﬁkation (TAV).

Kazman, R., Woods, S., and Carriere, S. (1998). Require-

ments for integrating software architecture and reengi-

neering models: CORUM II. In Proceedings Fifth

Working Conference on Reverse Engineering. IEEE

Comput. Soc.

Khadka, R., Reijnders, G., Saeidi, A., Jansen, S., and Hage,

J. (2011). A method engineering based legacy to soa

migration method. In 27th IEEE International Con-

ference on Software Maintenance (ICSM).

Menychtas, A. and Al., E. (2014). Software moderniza-

tion and cloudiﬁcation using the ARTIST migration

methodology and framework. Scalable Computing:

Practice and Experience.

Mohagheghi, P. (2010). Reuse and Migration of

Legacy Systems to Interoperable Cloud Services- The

REMICS project. In Mda4ServiceCloud. Springer,

Berlin, Heidelberg.

OMG (2011). Architecture-driven Modernization: Abstract

Syntax Tree Metamodel (ASTM)- Version 1.0. Object

Management Group.

OMG (2013). UML Testing Proﬁle (UTP), Version 1.2.

Sneed, H. M., Wolf, E., and Heilmann, H. (2010). Software-

Migration in der Praxis:

Ubertragung alter Soft-

waresysteme in eine moderne Umgebung. dpunkt Ver-

lag.

Zillmann, C., Winter, A., Herget, A., Teppe, W., Theurer,

M., Fuhr, A., Horn, T., Riediger, V., Erdmenger, U.,

Kaiser, U., Uhlig, D., and Zimmermann, Y. (2011).

The SOAMIG Process Model in Industrial Applica-

tions. In 15th European Conference on Software

Maintenance and Reengineering. IEEE.

Modular Construction of Context-Speciﬁc Test Case Migration Methods

541