I used this set of slides for a lecture I gave at the University of Bern on Dec 4, 2008.

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

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

3. { {
{ { {
{
} { {
}
} restructuring } }
} { } } }

4. Testing and Migration

5. Why test?

7. Many legacy systems don’t have tests

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

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

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

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

12. Write tests to enable evolution

13. g fram ework
Use a testin
setUp
assert
tearDown

14. Grow your test base incrementally

15. Test the interface, not the implementation

16. Record business rules as tests

17. Write tests to understand

18. g fram ework
Use a testin
setUp
assert
tearDown

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

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

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

22. Testing and Migration

23. Migration is a restructuring that
changes the underlying infrastructure

24. 1989

26. Big-bang migration often fails

27. Big-bang migration often fails
Users hate change

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

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

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

31. Involve the users

32. Build confidence

33. Conserve familiarity

34. Migrate
incrementally

35. Prototype the target solution

38. Throw-away vs. evolutionary prototypes

39. Always have a running version

40. Test after every change

41. Use the profiler before optimizing

42. Data needs to be preserved and available

43. :Legacy System
:Legacy Storage

44. :Legacy System :New System
:Legacy Storage :New Storage

45. :Legacy System :New System
:Bridge
:Legacy Storage :New Storage

46. :Legacy System :New System
:Bridge
:Legacy Storage :New Storage

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

48. Present the right interface

49. Public vs. published interface

50. Component
service()

51. Component
service()
replacingService()

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

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

54. Component
replacingService()

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

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

57. Client, v1
Component, v1

58. Client, v1
Component, v1 Component, v2
store
changes

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

60. Don’t jump.
Walk with little tested steps

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