Testing and Migration
Tudor Gîrba
www.tudorgirba.com

fo
rw
g
rin
ar
ee
d
gin
en
gin
en
ee
se
rin
erv
g
re
{ {
{ { {
{
} { {
}
} restructuring } }
} { } } }

{ {
{ { {
{
} { {
}
} restructuring } }
} { } } }

Testing and Migration

Why test?

Many legacy systems don’t have tests

Many legacy systems don’t have tests
Customers pay for features, not tests

Many legacy systems don’t have tests
Customers pay for features, not tests
You can’t test everything anyway

Many legacy systems don’t have tests
Customers pay for features, not tests
You can’t test everything anyway
Testing is akin to street-cleaning

Many legacy systems don’t have tests
Customers pay for features, not tests
You can’t test everything anyway
Testing is akin to street-cleaning
Real programmers don’t need tests

Write tests to enable evolution

g fram ework
Use a testin
setUp
assert
tearDown

Grow your test base incrementally

Test the interface, not the implementation

Record business rules as tests

Write tests to understand

g fram ework
Use a testin
setUp
assert
tearDown

ult to set up
diffic
But, le gacy is
setUp
assert
tearDown

aModel aStorage aClass
add(aClass)
store(aClass)
setModel(aModel)

aModel aStorage aClass
add(aClass)
store(aClass)
setModel(aModel)
6
casse etal 200
Du

Testing and Migration

Migration is a restructuring that
changes the underlying infrastructure

1989

Big-bang migration often fails

Big-bang migration often fails
Users hate change

Big-bang migration often fails
Users hate change
You need constant feedback to stay on track

Big-bang migration often fails
Users hate change
You need constant feedback to stay on track
Users just want to get their work done

Big-bang migration often fails
Users hate change
You need constant feedback to stay on track
Users just want to get their work done
The legacy data must be available during the transition

Involve the users

Build confidence

Conserve familiarity

Migrate
incrementally

Prototype the target solution

Throw-away vs. evolutionary prototypes

Always have a running version

Test after every change

Use the profiler before optimizing

Data needs to be preserved and available

:Legacy System
:Legacy Storage

:Legacy System :New System
:Legacy Storage :New Storage

:Legacy System :New System
:Bridge
:Legacy Storage :New Storage

:Legacy System :New System
:Bridge
:Legacy Storage :New Storage

e new town
a bridg e to th
Make
:Legacy System :New System
:Bridge
:Legacy Storage :New Storage

Present the right interface

Public vs. published interface

Component
service()

Component
service()
replacingService()

te inte rfaces
te obs ole
De preca
Component
service()
replacingService()

te inte rfaces
te obs ole
De preca
Component
service()
replacingService()

Component
replacingService()

ange?
on-breaking ch
or n
reaking
Is it a b
Component
service()
replacingService()

o refac torings
nges are due t
eaking API cha
80% of br
Component
service()
replacingService()
6
n son 200
Dig, Joh

Client, v1
Component, v1

Client, v1
Component, v1 Component, v2
store
changes

replay
changes
Client, v1 Client, v2
Component, v1 Component, v2
store
changes
7
Dig etal 200
e tal 2007
Denker

Don’t jump.
Walk with little tested steps

Tudor Gîrba
www.tudorgirba.com
creativecommons.org/licenses/by/3.0/