It's nice to work on Green Fields projects. But most of us aren't that lucky! Most organisations have large legacy code bases to maintain. And the legacy applications, ugly as they are, are often what generates the revenue! But legacy code bases are not easy to work with. Adding new features, or even fixing bugs, is slow and fraught with danger. Unexpected regressions are commonplace. Long testing cycles is the norm. In this talk we will look at some strategies that can enable you to add new features to legacy systems faster and more reliably. We will examine where the hold-ups typically are, and what We will learn how to write cost-effective automated regression tests suites, and how to use unit testing as a way to document your legacy code base for future work, and improve its quality along the way!

1. HELP! My Legacy Application is
Unmaintainable!
Reducing the cost of change in legacy code bases

2. Consulta
nt
Trainer
Mentor
Author
Speaker
Coder
John Fer
guson S
mar t

3. Legacy applications are difficult to
maintain

4. Legacy applications generate
revenue

5. What is a legacy application?
Old code base?

6. What is a legacy application?
Outdated technology

7. What is a legacy application?
“Legacy code is code without tests”!
!
- Michael Feathers

8. But what is wrong with legacy code?
Nothing…if you don’t need to change it much

9. Legacy code is bad when…
…it is hard to add new features

10. Legacy code is bad when…
…changes risk introducing regressions

11. Legacy code is bad when…
…poor coding style and/or lack of documentation
makes the code hard to understand

12. Legacy code is bad when…
…there are no automated tests

13. Legacy code is bad when…
…it prevents you from delivering as quickly as you would like

14. Why not just rewrite it all?

15. Over
&me,
new
features
get
harder
and
harder
to
add
Total cost to
maintain the
legacy
application
Cumulated effort
to add new
features
Cost
of
not
rewri&ng
Time

16. What do we really want?
We need to be able to make the changes we
need to make faster and more reliably

17. So how can we get changes out faster?
Build a safety net
Document the specifications

18. Build a safety net

19. Characterisation Test!
!
A means to describe (characterise) the actual behaviour of an
existing piece of software, and therefore protect existing
behaviour of legacy code against unintended changes.
!
Term coined by Michael Feathers

20. Broad, high level automated acceptance tests
Application

21. To write good automated tests
do not write tests

22. Write a user’s manual instead…
…but automate it

23. Automate user journeys

24. Organise your requirements
Browse the pr
o duct catalog
View pro duct
details
Search for pro
ducts

25. Organise your requirements
Browse the pr
o duct catalog
View pro duct
details
Search for pro
ducts

26. Organise your requirements
Browse the pr
o duct catalog
View pro duct
details
Search for pro
ducts

27. Illustrate behaviour using examples

32. Document your business rules

33. Document your business rules

35. Good automated acceptance tests have layers
Make them maintainable
Keep them tidy
Use layers!

36. Good automated acceptance tests have layers
Make them maintainable
Business
Rules
Business
Flow
Page/Component
interac&ons
Page/Component
details

37. Start with high-level requirements

38. Drill down into more detailed requirements

39. Illustrate a requirement with tests

40. Documenting the specifications

41. A question of style
Spock
context["When cumulating Frequent Flyer points"] = () =>
{
it["should earn points for each flight"] = () =>
{
member.earnStatusPoints(100);
member.earnStatusPoints(50);
member.getStatusPoints().should_be(150);
};
!
it["should get upgrade when enough points are earned"] = () =>
{
member.earnStatusPoints(00);
!
member.getStatus().should_be(Status.Silver);
};
};
NSpec
}
}

42. A question of style
JUnit

43. Adding new features
TDD/BDD outposts in the wilderness

44. Discussion Time!

45. References
BDD In Action - Manning
http://thucydides.info
http://www.wakaleo.com