Embed Size (px)
DESCRIPTION
I used this set of slides for a lecture I gave at the University of Bern on Dec 4, 2008.
Citation preview
Testing and Migration
Tudor Gîrbawww.tudorgirba.com
restructuring
reve
rse
engin
eerin
gforward engineering
}
{
}
{
}
{
}
{}
{
}
{
}
{}
{
}
{
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
setUp
assert
tearDown
Use a testing framework
Grow your test base incrementally
Test the interface, not the implementation
Record business rules as tests
Write tests to understand
setUp
assert
tearDown
Use a testing framework
setUp
assert
tearDown
But, legacy is difficult to set up
aModel aClass
add(aClass)
aStorage
store(aClass)
setModel(aModel)
Ducasse etal 2006
aModel aClass
add(aClass)
aStorage
store(aClass)
setModel(aModel)
Testing and Migration
Migration is a restructuring thatchanges 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
Migrateincrementally
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
:Legacy Storage :New Storage
:Bridge
:Legacy System :New System
:Legacy Storage :New Storage
:Bridge
:Legacy System :New System
:Legacy Storage :New Storage
:Bridge
Make a bridge to the new town
Present the right interface
Public vs. published interface
Componentservice()
Componentservice()replacingService()
Componentservice()replacingService()
Deprecate obsolete interfaces
Componentservice()replacingService()
Deprecate obsolete interfaces
Component replacingService()
Componentservice()replacingService()
Is it a breaking or non-breaking change?
Dig, Johnson 2006
Componentservice()replacingService()
80% of breaking API changes are due to refactorings
Client, v1
Component, v1
storechanges
Client, v1
Component, v1 Component, v2
Dig etal 2007
storechanges
replaychanges
Client, v1
Component, v1 Component, v2
Client, v2
Denker etal 2007
Don’t jump.Walk with little tested steps
Tudor Gîrbawww.tudorgirba.com
creativecommons.org/licenses/by/3.0/
