Concept-based Co-migration of Test Cases

Ivan Jovanovikj, Enes Yigitbas, Stefan Sauer and Gregor Engels

Software Innovation Lab, Paderborn University, F

urstenalle 11, Paderborn, Germany

Keywords:

Test Case Migration, Co-migration, Co-evolution, Concept Modeling, Method Engineering.

Abstract:

Software testing plays an important role in software migration as it veriﬁes its success. As the creation of test

cases is an expensive and time consuming activity, whenever test cases are existing, their reuse should be con-

sidered, thus implying their co-migration. During co-migration of test cases, two main challenges have to be

addressed: situativity and co-evolution. The ﬁrst one suggests that when a test migration method is developed,

the situational context has to be considered as it inﬂuences the quality and the effort regarding the test case

migration. The latter suggests that the changes that happen to the system have to be considered and eventually

reﬂected to the test cases. We address these challenges by proposing a solution that applies situational method

engineering extended with co-evolution analysis. The development of the test migration method is centered

upon the identiﬁcation of concepts describing the original tests and original system. Furthermore, the impact

of the different realization of the system concepts in source and target environments is analyzed as part of

the co-evolution analysis. Lastly, based on this information, a selection of suitable test migration strategies is

performed.

1 INTRODUCTION

Software migration is a well-established method for

transferring software systems in new environments

while keeping the data and the functionality of the

system (Bisbal et al., 1999). A widely used validation

technique in software migration projects is software

testing. As test case design, in general, has been seen

as an expensive and time consuming activity (Sneed,

1999), reusing existing in migration context test cases

is certainly worth considering. Reusing test cases can-

not only substantially reduce the cost of testing the

migrated system, but can also help to retain valuable

information about the expected functionality of the

original system and thus the desired functionality of

the migrated system.

The migration of the test cases comes down to the

problem of co-migration, i.e., the test cases have to

be migrated along with the system as their migra-

tion is dependent on the system migration. The co-

migration is practically deﬁned by the co-evolution of

the test cases and the corresponding system. In gen-

eral, co-evolution refers to two or more objects evolv-

ing alongside each other, such that there is a relation-

ship between the two that must be maintained (Mens

and Demeyer, 2008). In our case, this refers to the

test cases evolving alongside the code being migrated,

such that the test cases remain correct for testing

the migrated system. Hence, co-evolution analysis

should be incorporated in the test case migration in

order to provide a proper evolution of the test cases

and thus, their proper migration.

When performing a test migration, a transforma-

tion method is required which serves as a techni-

cal guideline and describes the activities necessary to

perform, tools to be used, and roles to be involved

in order to migrate given test cases. The develop-

ment of the transformation method is a very impor-

tant task as it inﬂuences the overall success of the

migration project in terms of effectiveness (e.g., non-

functional properties of the migrated system) and ef-

ﬁciency (e.g., the time required or the budget). To

achieve this, the situational context of the migration

project should be taken into consideration. The sit-

uational context comprises different inﬂuence factors

like characteristics of the original system or target en-

vironment, the goals of the stakeholders etc. Con-

cerning test case co-migration, the situational context

gets even more complex as beside the inﬂuence fac-

tors of the system migration, test-speciﬁc inﬂuence

factors like characteristics of the original test cases or

test target environment have to be considered as well.

To develop a situation-speciﬁc transformation method

is an important and challenging task, as the previ-

ously discussed co-evolution aspect should be incor-

porated when identifying the situational context from

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

Concept-based Co-migration of Test Cases.

DOI: 10.5220/0009171404490456

In Proceedings of the 8th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2020), pages 449-456

ISBN: 978-989-758-400-8; ISSN: 2184-4348

449

Concept

Identiﬁcation

Impact

Model

Concept

Model

Situational

Context

Model

Co-Evolution

Analysis

Inﬂuence

Factor

Identiﬁcation

Method

Patterns

Method

Fragments

Situational Context Identification

Method Development Method Enactment

Tool

Implementation

Transformation

Situation-Speciﬁc

Test Migration Method

Speciﬁcation

Situation-Speciﬁc

Test Tool Chain

Method Base

Method

Construction

Figure 1: Overview of the Method Engineering Process with the main focus on the Situational Context Identiﬁcation Activity.

both system and test perspectives.

In order to address the previously mentioned chal-

lenges, based on the Method Engineering Framework

for Situation-Speciﬁc Software Transformation Meth-

ods (MEFiSTo) (Grieger, 2016), we provide a solution

that combines techniques from Situational Method

Engineering (SME) (Henderson-Sellers et al., 2014)

and Software Evolution (Mens and Demeyer, 2008).

Figure 1 depicts the overview of our method engi-

neering process whose activities are split in two main

disciplines: Method Development and Method En-

actment. Beside the Method Engineering Process,

another integral part of the solution approach is the

Method Base. The Method Base contains the build-

ing blocks, Method Fragments and Method Patterns,

needed for assembling the test migration method.

Method Fragments are atomic building blocks of a

migration method, whereas Method Patterns repre-

sent a proven migration strategy and indicate which

fragments are necessary and how to assemble them

together. The suitability of each pattern to a certain

situation is expressed by a set of characteristics. Us-

ing the Method Base, the Method Engineering Pro-

cess guides the development and the enactment of the

situation-speciﬁc test migration method. By perform-

ing activities of the Method Development discipline, a

situation-speciﬁc test method gets developed. It com-

prises the following two activities: Situational Con-

text Identiﬁcation and Transformation Method Con-

struction. As our focus is on the incorporation of the

co-evolution analysis in the method engineering pro-

cess, in this paper, we mainly focus on the Situational

Context Identiﬁcation activity. During this activity,

the situational context is analyzed and characterized

from both system migration and testing perspective.

Firstly, in the Concept Identiﬁcation activity, both the

source and the target tests and system are represented

as a set of concepts by applying concept modeling.

Then, based on this concept representation in terms

of a Concept Model the impact of the system changes

on the test cases is identiﬁed and captured in terms

of an Impact Model in the Co-Evolution Analysis ac-

tivity. Lastly, as part of the Inﬂuence Factor Identi-

ﬁcation activity, the inﬂuence factors are identiﬁed.

Having the context information collected in terms of

a Situational Context Model, the Method Construc-

tion activity can be initiated and a situation-speciﬁc

test migration method gets constructed. The over-

all outcome of Method Development is a Situation-

Speciﬁc Test Migration Method Speciﬁcation which

deﬁnes how to do the migration by deﬁning the activ-

ities to be performed and the artifacts that should be

generated. During the ﬁrst activity of Method Enact-

ment, namely the Tool Implementation, a Situation-

Speciﬁc Tool Chain is developed that is required for

the automation of the migration method. Thereafter,

during the Transformation activity, the test migration

method is enacted as deﬁned in the test migration

method speciﬁcation.

The structure of the rest of the paper is as follows:

In Section 2, we introduce the running example that

we use throughout the paper. In Section 3, we present

the identiﬁcation of the concepts. In Section 4, the co-

evolution analysis is explained. The inﬂuence factor

identiﬁcation is introduced in Section 5. In Section 6,

we discuss related work and at the end, in Section 7,

we conclude our paper and give an outlook on future

work.

2 RUNNING EXAMPLE

As a running example, we use a real-world migra-

tion project (Schwichtenberg et al., 2018), where

the problem of enabling cross-platform availability of

the well-known Eclipse Modeling Framework (EMF)

was addressed. EMF is highly adopted in practice

and generates Java code from platform independent

models with embedded Object Constraint Language

(OCL) expressions. EMF provides an implementation

of OCL which is an OMG standardized formal lan-

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

450

guage used to describe expressions over UML mod-

els. As feature-complete Ecore and OCL runtime

APIs are not available for some platforms, their func-

tionality has to be re-implemented for each of them.

The EMF Code Generator component embeds native

string-based OCL expressions directly in the emitted

Java code with the help of Java Emitter Templates.

The interpretation of the OCL expressions is dele-

gated by the EMF Runtime API to the OCL Inter-

preter. The interpreter ﬁrstly parses the string-based

OCL expressions and evaluates them at run-time, i.e.,

in Just-In-Time (JIT) manner.

CrossEcore (Schwichtenberg et al., 2018), a cross-

platform enabled modeling framework, addresses this

problem by providing a code generation of platform-

speciﬁc code from platform-independent Ecore mod-

els with embedded OCL expressions. The OCL com-

piler (OCL Visitor), as part of the CrossEcore Code

Generator, transcompiles the string-based OCL ex-

pressions into expressions of the target programming

language. Hence, the OCL expressions are trans-

lated at design-time and ahead of compilation, i.e., in

Ahead-Of-Time (AOT) manner.

As EMF’s OCL implementation is well-tested,

with more than 4000 JUnit test cases being available

on public code repositories

, their reuse was a very

intuitive solution to be selected. However, their reuse

was not that straightforward as CrossEcore’s OCL im-

plementation was completely different in comparison

to EMF’s OCL implementation. As the migration was

performed to different target platforms, i.e., program-

ming languages, a ”one-size-ﬁts-all” approach is not

the perfect solution. This implies usage of a situation-

speciﬁc transformation method, for example, suitable

for the situation characterized by the target language

or the target testing platform. This example scenario

is used thoughout the paper to present each of the ac-

tivities of the situational context identiﬁcation.

3 CONCEPT IDENTIFICATION

The purpose of the Concept Identiﬁcation activity is

to model a decomposition of the system and the test-

ing artifacts into distinct parts for both the source

and the target environment. We use the principles

of Concept Modeling (Kozaczynski et al., 1992) to

represent the functionality of the system as a set of

concepts. The concepts are split into two differ-

ent groups, namely language concepts and abstract

concepts. Language concepts directly correspond to

syntactic entities of the programming language, like

http://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/tests/

variables, declarations, statements etc. (Kozaczynski

et al., 1992). The abstract concepts, on the contrary,

represent language-independent ideas of computation

and problem solving methods (Kozaczynski et al.,

1992). Abstract concepts are further classiﬁed into ar-

chitectural and programming concepts. The architec-

tural concepts are associated with interfaces or com-

ponents whereas the programming concepts represent

a general coding strategy, data structure or algorithm.

Concepts can be related to each by is-a relation, to

express a hierarchy between concepts, and consists-of

relation to express dependencies between concepts.

In (Grieger, 2016), when applying the idea of Concept

Modeling to software modernization, three classes of

concepts are distinguished: original system concepts,

target system concepts, and shared system concepts.

Regarding the original system, the language concepts

are determined by the language elements that are al-

ready used, whereas language concepts regarding the

target system concepts are those language concepts

that will be used after the transformation. Finally, a

shared concept is an abstract concept of the original

system that can be realized in the target environment.

All in all, the concept model is deﬁned as a directed,

acyclic and connected graph. The nodes represent

the concepts, whereas the edges between them rep-

resent is-a or consists-of relations. In the following,

we present the concept model as well as the concept

identiﬁcation process.

As shown in Figure 2, our Concept Model is a

part of the Situational Context Model. The Con-

cept Model, which extends the concept model intro-

duced in (Grieger, 2016), can contain a set of Con-

cerns which can further contain sub-Concerns and

a set of Concepts. Beside the SystemConcept sub-

class which expresses system related concepts, the

ConceptModel contains an additional subclass for ex-

pressing test-related concepts, namely the TestCon-

cept class. This class has additional subclasses like

the AbstractTestConcept which is further specialized

into ProgrammingTestConcept and ArchitecturalTest-

Concept, and the LanguageTestConcept for express-

ing concrete syntactic entities related to testing. As

deﬁned by the conceptClass attribute in the Concept

class, each Concept belongs to one out of six classes

as deﬁned by the enumeration type ConceptClass.

Furthermore, a Concept can be related to other con-

cepts by the consists-of and is-a relations. The in-

variants of the concept model instances are ensured

by the OCL constraints. For example, the two OCL

constraints shown in Figure 2 deﬁne that the target of

a consists-of relation for a SystemConcept or a Test-

Concept can only be another SystemConcept or Pro-

grammingConcept, respectively.

Concept-based Co-migration of Test Cases

451

Constraint Inheritance

Artifact

Composition

Association

TestConcept

LanguageTestConcept AbstractTestConcept

ProgrammingTestConcept ArchitecturalTestConcept

self.consistsOf.oclIsTypeOf(TestConcept)

SystemConcept

LanguageConceptAbstractConcept

ProgrammingConcept ArchitecturalConcept

self.consistsOf.oclIsTypeOf(SystemtConcept)

Concept

SituationalContextModel ConceptModel

Concern

concerns

concept

consistsOf

<<enumeration>>

ConceptClass

SharedConcept

SourceConcept

TargetConcept

SharedTestConcept

SourceTestConcept

TargetTestConcept

isA

concern

conceptClass :ConceptClass

Figure 2: The concept metamodel to formalize the concept models in co-migration context.

The concept identiﬁcation process deﬁnes the nec-

essary steps to be performed in order to capture the

test and system concepts for both source and target

environment. The process is target-driven as the de-

sired transformation outcome that is desired delivers

the concepts to be identiﬁed. Firstly, a set of con-

cerns is identiﬁed based on system and test target ar-

chitectures, which in turn provides a coarse-grained

structure of the concept model. The next three ac-

tivities (A - C) are performed repeatedly for each

concern. Firstly, concepts for the current concern

are identiﬁed based on the target system and the tar-

get tests (A). This activity is based solely on the ex-

perience of the expert or by evaluating supporting

materials like development or test tutorials. Fig-

ure 3 shows the concept model of the example in-

troduced in Section 2. From system perspective, we

have identiﬁed the abstract architectural concept OCL

(Ahead-of-Time) which represents the realization of

the shared abstract concept Object Constrain Lan-

guage (OCL) in CrossEcore. It further consists of

a concrete programming concept named Language-

speciﬁc OCL-Expression, which represents the OCL

expression that is deﬁned in CrossEcore by using lan-

guage constructs. This class consists of Derived Ex-

pression, Operation, and Constraint. The ﬁrst two

programming concepts consist of Functions, whereas

the last one is a Logical Expression. From testing

perspective, we have identiﬁed the OCL Test Case

as shared abstract test concept. As a target test con-

cept we have identiﬁed the language test concept OCL

Test Case (AOT), which further consists of the lan-

guage test concepts Action, Expected Result, and As-

sertion. Secondly, by performing a superﬁcial analy-

sis of the original system and original tests the identi-

ﬁed concepts are validated (B). This is necessary, be-

cause the concepts have so far been identiﬁed with-

out considering the original system and the original

tests. Thirdly, a concluding source-driven identiﬁca-

tion takes place as original system and original tests

are analyzed to eventually identify additional con-

cepts that are speciﬁc to the original system and the

original test cases (C). From system perspective, we

have identiﬁed the abstract architectural concept OCL

(Just-in-Time) which represents the realization of the

shared abstract concept Object Constrain Language

(OCL) in EMF. It consists of a concrete program-

ming concept named Native OCL-Expression which

represents the OCL expression in EMF which further

consists of Derived Expression, Operation, and Con-

straint all of them, as typical for EMF, being String

Literals. From testing perspective, we have identiﬁed

the source test concept OCL Test Case (AOT). This

concept consists of Assertion, which further consists

of the two language test concepts Action and Expected

Result.

4 CO-EVOLUTION ANALYSIS

Having identiﬁed the concepts, from both system and

test perspective, in terms of a concept model, in this

step a co-evolution analysis is performed. According

to (Mens and Demeyer, 2008), the co-evolution pro-

cess consists of several activities from which Change

Detection and Impact Analysis are relevant during the

situational context identiﬁcation. During Change De-

tection, all changed parts of the system being mi-

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

452

Object Constraint

Language (OCL)

Shared System Concept

OCL

(Just-in-Time)

OCL

(Ahead-of-Time)

Native

OCL-Expression

Language-speciﬁc

OCL-Expression

Derived

Expression

Operation Constraint

Derived

Expression

Operation Constraint

String

Literal

String

Literal

String

Literal

Function Function

Logical

Expression

Source System Concepts Target System Concepts

OCL

Interpeter

OCL

Comiplier

contains-trace

OCL Test Case

(AOT)

Action

Expected

Result

Assertion

OCL Test Case

(JIT)

Source Test Concepts

Assertion

Action

Expected

Result

Target Test Concepts

Shared Test Concept

consists-of relation

is-a relation

Language Concept

Abstract Concept

Set of Concepts

corresponds-to-trace

Abstract Test Concept

Language Test Concept

Figure 3: Concept model and impact model of the example scenario.

Constraint Inheritance

Artifact

Composition

Association

source

self.source.oclIsTypeOf(SystemConcept) &&

self.target.oclIsTypeOf(SystemConcept)

target

ContainsTraceCorrespondsToTrace

TestConcep t

(from Concept)

SystemConcept

(from Concept)

Concept

(from Concept)

self.source.oclIsTypeOf(TestConcept) &&

self.target.oclIsTypeOf(SystemConcept)

trace

Impact

SituationalContextModel ImpactModel

Trace

Figure 4: The impact metamodel to formalize the relation between the test and system concepts in the co-migration context.

grated are identiﬁed. Having identiﬁed these changes,

all affected parts of the test cases are identiﬁed in the

next step called Impact Analysis. Finally, an estimate

of the effort required to accomplish the changes to-

gether with involved risks is made. Therefrom, the

main idea is to describe the changes that happened to

the system by identifying and relating corresponding

source and target system concepts to each other.

Then, the relation between the source and target

test concepts to their corresponding system concepts

is also established. Having these relations, the impact

of the system changes on the test cases can be de-

rived. In order to enable these activities, we provide a

metamodel (shown in Figure 4) that formalizes the re-

lations between the system and test concepts in terms

of traces. Furthermore, we also introduce the impact

analysis process which deﬁnes the necessary actions

to perform the impact analysis.

As can be seen in the upper left of Figure 4, we

consider the Impact Model to be a part of the Situ-

ationalContextModel. The ImpactModel can contain

a set of Traces which can be either CorrespondsTo-

Trace or a ContainsTrace. Each Trace has a source

and a target Concept. In the case of a Correspond-

sToTrace, as deﬁned by the related OCL constraint,

both target and source are of the type SystemConcept.

On the other hand, a ContainsTrace, as deﬁned by the

related OCL constraint, has as target a TestConcept

and a SystemConcept as source.

As previously introduced, the co-evolution anal-

ysis addresses two main activities, namely, the detec-

tion of the changes and the impact analysis. Firstly, on

the basis of the input concept model, for each source

system concept, a corresponding target system con-

cept is identiﬁed and a CorrespondsToTrace is cre-

ated. Then, each test concept, both source and target,

is related to the corresponding system concept that it

tests (contains) by establishing a ContainsTrace. Af-

Concept-based Co-migration of Test Cases

453

ter the second activity is done, a complete traceabil-

ity model is produced in terms of an ImpactModel.

The traces in the ImpactModel express the actual im-

pact. Related to the example shown in Figure 3,

the source system concept Native OCL-Expression

corresponds to the target system concept Language-

speciﬁc OCL-Expression. Regarding the test con-

cepts, on the one hand, the source system concept Na-

tive OCL-Expression is contained by the source test

concepts Action and Assertion. On the other hand,

the corresponding system target concept Language-

speciﬁc OCL-Expression is contained by the target

test concepts Action, Expected Result, and Assertion.

These relations suggest indirectly in which way the

tests are inﬂuenced by the system changes. Namely,

the test cases have to be changed in a way that the con-

tained part of the system should be changed in accor-

dance to the correspondence relation between the sys-

tem concepts Native OCL-Expression and Language-

speciﬁc OCL-Expression.

5 INFLUENCE FACTOR

IDENTIFICATION

In this activity, similarly to (Grieger, 2016), for each

identiﬁed concept, a method pattern is chosen. In or-

der to decide which test method pattern to use, one

needs to systematically search for characteristics that

inﬂuence pattern’s efﬁciency or effectiveness. Each

pattern has a set of characteristics which actually ex-

press its suitability to a certain situation. To support

the inﬂuence factor identiﬁcation, we provide an in-

ﬂuence factor metamodel and a general guideline for

identifying inﬂuence factors.

The InﬂuenceFactorModel is a part of the Situa-

tionalContextModel (Figure 5). It can contain a set

of InﬂuenceFactors, further split into two subclasses:

TestInﬂuenceFactor and SystemInﬂuenceFactor. An

inﬂuence factor is deﬁned as a characteristic of a co-

migration project that has some impact on the efﬁ-

ciency or effectiveness of a transformation method.

The TestInﬂuenceFactor is used to describe the test-

related inﬂuence factors for both source and target en-

vironments as well as organizational and test tooling-

related inﬂuence factors. Similarly, one can use

the SystemInﬂuenceFactor to specify inﬂuence factors

from system perspective. Note that an additional class

appears, namely the TransformationInﬂuenceFactor,

which has the role to specify the inﬂuence that the

system migration could eventually have on the test

case migration. A given Concept is associated with

a set of suitable MethodPatternAlternatives, showing

that each MethodPatternAlternative can be inﬂuenced

by InﬂuenceFactors. Then, one pattern can be cho-

sen to be applied, which is expressed by the Applied-

MethodPattern class. For both MethodPatternAl-

ternative AppliedMethodPattern classes, we distin-

guish between test and system migration patterns,

indicated by the subclasses SystemMethodPatternAl-

ternative and TestMethodPatternAlternative, and Ap-

pliedSystemMethodPattern and AppliedTestMethod-

Pattern, respectively. For example, the realization of a

concept in the original system will inﬂuence all suit-

able method patterns. However, the InﬂuenceFactor

only needs to be speciﬁed once and can be linked

to all affected MethodPatternAlternatives. In order

to ensure invariants in the model, OCL constraints

are used. For example, the OCL constraint related to

the class TestInﬂuenceFactor deﬁnes that each TestIn-

ﬂuenceFactor can inﬂuence only a TestMethodPat-

ternAlternative.

In the following, we describe the necessary steps

for instantiating of an inﬂuence factor model. Firstly,

a ﬁne-grained analysis of the test and system realiza-

tion, both source and target, for each concept is per-

formed. In contrast to the coarse-grained superﬁcial

analysis from context identiﬁcation, here we identify

inﬂuence factors that may allow exclusion of some of

the possible test method patterns, thus reducing the

overall analysis effort. For example, if the realization

of the given concept in the original and the target envi-

ronment is signiﬁcantly different, the patterns which

do not include conceptual transformation are not suit-

able. Once a set of suitable test method patterns is

obtained, inﬂuence factors for each pattern are iden-

tiﬁed and described. In order to systematize the pro-

cess of identifying inﬂuence factors, each test method

pattern is analyzed from the perspective of the com-

prising method fragments. For example, as illustrated

in the third pattern (from left to the right) in Figure 6,

a method fragment deﬁnes that a parser is needed. In

this case, the availability of such a parser is an inﬂu-

ence factor. The situational context model contains

the identiﬁed abstract test concept, namely the OCL

Test Case, its realization in the source test environ-

ment as well as the planned realization in the target

test environment. Additionally, it also contains the as-

sessed suitability of the possible test method patterns,

in terms of effectiveness and efﬁciency. For exam-

ple, regarding the leftmost method pattern, the testers

would be challenged with re-implementing the tests

cases as they are not experienced with CrossEcore.

The second pattern has been identiﬁed as not suitable

as it does not provide a way to interact directly with

the test concepts like expected result or the test ac-

tion. Having the inﬂuence factors identiﬁed, all suit-

able test method patterns are analyzed and assessed.

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

454

Constraint Inheritance

Artifact

Composition

Association

Concept

MethodPatternAlternative

type: MethodPatternType

pros: String

cons: String

inﬂuences

1..*

suitableMethodPattern

chosen

0..1

1..1

1..*

SituationalContextModel InﬂuenceFactorModel

InﬂuenceFactor

description :String

implication :String

AppliedMethodPattern

rationale: String

1..*

appliedMethodPattern

inﬂuenceFactor

Influence

self.suitableMethodPattern.oclIsTypeOf

(SutiableTestMethodPattern)

self.suitableMethodPattern.oclIsTypeOf

(SutiableSystemMethodPattern)

ToolingTestInﬂuenceFactor

self.appliedMethodPattern.oclIsTypeOf

(AppliedSystemMethodPattern)

<<enumeration>>

MethodPatternType

LanguageTransformation

ConceptualTransformation

Reimplementation

CodeRemoval

LanguageTestTransformation

ConceptualTestTransformation

TestReimplementation

TestCodeRemoval

AppliedSystemMethodPattern

SystemConcept

SystemMethodPatternAlternative

TargetSystemInﬂuenceFactor

OriginalSystemInﬂuenceFactor

TransformationInﬂuenceFactor

SystemInﬂuenceFactor

OrganizationalInﬂuenceFactor

TestInﬂuenceFactor

TestToolingInﬂuenceFactor

OrganizationalInﬂuenceFactor

OriginalTestInﬂuenceFactor

TargetTestInﬂuenceFactor

self.inﬂuences.oclIsTypeOf

(TestMethodPatternAlternative)

AppliedTestMethodPattern

TestMethodPatternAlternative

TestConcept

self.appliedMethodPattern.oclIsTypeOf

(AppliedTestMethodPattern)

Figure 5: The inﬂuence factor metamodel for the co-migration context.

OCL Test Case

(AOT)

OCL Test Case

(JIT)

Shared

Original Test

Target Test

Testers

unexperienced

in target

environment

Not suitable

Meatmodel

unavailable

Parser

available

migration strategy

alternative

is-a relation

class of concepts

abstract test concept

language test concept

indicator on the

efficiency or

effectiveness

test migration

pattern

Transformation

available

automated

transformation

Activity Speciﬁcation

manual

transformation

Model Code

Artifact Speciﬁcation

Figure 6: Excerpt of the situational context model showing

the evaluated suitability of the test method patterns.

6 RELATED WORK

Different categories of method engineering ap-

proaches exist, namely those that provide ﬁxed meth-

ods, a selection out of a set of ﬁxed methods, con-

ﬁguration of a method, tailoring a method or a mod-

ular construction of the method (Grieger, 2016).

Here, we only consider the last two, as they pro-

vide higher level of ﬂexibility. The method tailor-

ing approaches enable tailoring of a provided method,

which can be changed arbitrarily (REMICS (Mo-

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

ARTIST (Menychtas et al., 2014). The problem is,

however, that the process of changing the provided

method is not guided by a method engineering pro-

cess. The approaches that provide modular construc-

tion of a method rely on a set of predeﬁned building

blocks for methods and a method engineering pro-

cess that guides the method construction. A method

engineering approach that enables modular construc-

tion is presented in (Khadka et al., 2011), but is spe-

ciﬁc for migration to service-oriented environments.

The MEFiSTO framework (Grieger, 2016) overcomes

this issue by providing a general solution for modular

construction of situation-speciﬁc migration methods.

However, all of these methods do not provide support

for migration of test cases (except ARTIST (Meny-

chtas et al., 2014) to some extent), namely the con-

sideration of the test context, as well as the analy-

sis of the impact that the system changes have on the

test cases. In the area of test case evolution, work is

predominantly oriented to the continuous evolution of

test cases with the system. Compared to the evolution

of test cases in a migration setting, it is much more

ﬁne-grained. In (Farooq et al., 2010), a model-based

regression testing approach is proposed for evolving

systems with ﬂexible tool support. However, this

method does not address the conceptual changes in

the system migration as well as their impact on the

Concept-based Co-migration of Test Cases

455

test cases. (Mirzaaghaei et al., 2012) provides a semi-

automatic approach that supports test suite evolution

through test case adaptations by automatically repair-

ing and generating test cases during software evolu-

tion. This approach deals with the problem of re-

pairing existing test cases and generating new ones to

react to incremental changes in the software system.

Lastly, (Rapos, 2015) proposes a method for improv-

ing the model-based test efﬁciency by co-evolving

test models alongside system models. To enable this,

software model evolution patterns and their effects on

test models are analyzed. As all these approaches deal

with incremental changes, none of them is able to de-

tect conceptual changes.

7 CONCLUSION AND FUTURE

WORK

In this paper, we presented a method engineering pro-

cess that enables a modular construction of situation-

speciﬁc test migration methods. The process consists

of two main disciplines, namely method development

and method enactment, and relies on a method base.

The focus in this paper is on the method develop-

ment, particularly on the situational context identiﬁ-

cation. Firstly, the identiﬁcation of system and tests

concepts realized in both source and target environ-

ments is performed. Then, the different realization

of the system and test concepts is analyzed as part

of the co-evolution analysis. Finally, test and sys-

tem inﬂuence factors are identiﬁed and, based on this

information, a selection of a suitable test migration

strategy is performed. As future work we plan to de-

velop tool support for the activities of the proposed

approach, e.g., to support the modeling of the situ-

ational context. Furthermore, automation of the im-

pact analysis based on the obtained concept models is

also planned. Additionally, a quality analysis of the

constructed test migration methods regarding quality

criteria like completeness or correctness is planned.

REFERENCES

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

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

rections. IEEE Software.

Farooq, Q., Iqbal, M. Z. Z., Malik, Z. I., and Riebisch, M.

(2010). A model-based regression testing approach

for evolving software systems with ﬂexible tool sup-

port. In 2010 17th IEEE International Conference and

Workshops on Engineering of Computer Based Sys-

tems, pages 41–49.

Grieger, M. (2016). Model-Driven Software Modern-

ization: Concept-Based Engineering of Situation-

Speciﬁc Methods. PhD thesis, Paderborn University.

Henderson-Sellers, B., Ralyt

e, J.,

Agerfalk, P. J., and Rossi,

M. (2014). Situational method engineering. In

Springer Berlin Heidelberg.

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).

Kozaczynski, W., Ning, J., and Engberts, A. (1992). Pro-

gram concept recognition and transformation. IEEE

Transactions on Software Engineering.

Mens, T. and Demeyer, S. (2008). Software Evolution.

Springer, 1 edition.

Menychtas, A., Konstanteli, K., Alonso, J., Orue-

Echevarria, L., Gorronogoitia, J., Kousiouris, G.,

Santzaridou, C., Bruneliere, H., Pellens, B., Stuer,

P., Strauss, O., Senkova, T., and Varvarigou, T.

(2014). Software modernization and cloudiﬁcation us-

ing the ARTIST migration methodology and frame-

work. Scalable Computing: Practice and Experience.

Mirzaaghaei, M., Pastore, F., and Pezze, M. (2012). Sup-

porting test suite evolution through test case adapta-

tion. In 2012 IEEE Fifth International Conference on

Software Testing, Veriﬁcation and Validation, pages

231–240.

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

Legacy Systems to Interoperable Cloud Services-

The REMICS project. In Mda4ServiceCloud 2010.

Springer.

Rapos, E. J. (2015). Co-evolution of model-based tests for

industrial automotive software. In 2015 IEEE 8th In-

ternational Conference on Software Testing, Veriﬁca-

tion and Validation (ICST), pages 1–2.

Schwichtenberg, S., Jovanovikj, I., Gerth, C., and Engels,

G. (2018). Poster: Crossecore: An extendible frame-

work to use ecore and ocl across platforms. In 2018

IEEE/ACM 40th International Conference on Soft-

ware Engineering: Companion (ICSE-Companion).

Sneed, H. (1999). Risks involved in reengineering projects.

In Sixth Working Conference on Reverse Engineering,

pages 204–211.

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 2011 15th European Conference on Software

Maintenance and Reengineering. IEEE.

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

456