This document discusses test driven development (TDD) and how it can be applied to legacy code. It describes the TDD process and patterns for writing tests. When applying TDD to legacy code, it recommends identifying change points and inflection points in the code. Tests should be written to cover the inflection point by breaking dependencies. Then changes can be made using the full TDD process, and the covered code can be refactored.

1. Test Driven Development
Working with Legacy Code
Guy Davis
Pason Systems

2. Introduction
TDD is a changed mindset for development

One of the cornerstones of the Agile movement

Rejection of the defined engineering approach

No detailed designs set in stone up front
−
Embraces change through refactoring
−
Result is more cohesive and less coupled code

Regression test bed and easier integration


3. TDD Process
Complex view
1. Add a little test
2. Run all tests and fail
Simple view
3. Make a little change
1. Make a test 4. Run all the tests and
succeed
2. Make it run
5. Refactor to remove
duplication
3. Make it right

4. Introductory Exercise
Given three integers

representing the length
of the sides of a triangle
return:
1 if equilateral

2 if isosceles

3 if scalene

Throw an exception if

not well formed.

5. Writing tests
Chose a simple test first, use small steps...

When you have a list of tests, order them to get most

benefit up front.
Forces you to define interfaces early on

One thing at a time; keep a to-do list

What to test:

Requirements, assumptions, boundary cases
−
Goal is to get 100% code coverage with tests
−

6. Making tests run
TDD book offers three main approaches:

Fake It
−
Triangulation
−
Obvious Implementation
−
Goal is to get a passing test ASAP

The longer a test is failing, the less confident you
−
are

7. Fake It
Purpose is to get test running ASAP

Ignore coding conventions

Example: addition operation

Why?

Let's us take little steps...
−
Provides more refactoring confidence
−
Keeps work focused
−

8. Triangulation
How can we abstract conservatively with tests?

Example: addition operation

Safest way to abstract an operation

Allows for very small steps:

Why are small steps important?
−
Do you always want to take small steps?
−

9. Obvious Implementation
When small steps are too slow

Simply implement the solution you see

Faster, but...

Important to watch that bar isn't red for long or
−
often
Harder: solving both “code that works” and “clean
−
code” at the same time
Shouldn't keep getting test failures doing this
−

10. Make it right
Remove code duplication (including tests)

Meet coding standards

Refactor code

Reconcile differences
−
Isolate change
−
Move method
−
Extract method / Inline method
−
Extract interface
−

11. Patterns
Red Bar Patterns
One step test

TDD Patterns
Starter test

Isolated test

Explanation test

Test list

Learning test

Test first

Regression test

Assert first

Evident data


12. Patterns
Green Bar Patterns
Testing Patterns
Fake it

Child test

Triangulate

Obvious
Mock object


Implementation
Log string

One to many

Crash test dummy

Broken test

Clean check-in


13. TDD of Legacy code
1. Identify change points
2. Find an inflection point
3. Cover the inflection point
a) Break the dependencies
b) Write tests
4. Make changes
5. Refactor the covered code

14. Change Points
Where will changes need to be made in code?

Don't assume the first spot you find is the best

Approach resulting in fewest changes may be
−
good?
What about approach using simplest design?
−
Better to work in area with existing unit tests
−
Debuggers are useful in this stage


15. Inflection Point
A narrow interface to a set of classes or functions

Any changes in classes behind an inflection point are

either detectable at the inflection point or
inconsequential to the application.
Inflection points determined by compile time and

run time dependencies and code behavior.
What are some examples from the your project?


16. Covering an Inflection Point
Covering with unit tests (islands of test)

Legacy code: no tests means lots of dependencies

If class, try to create an instance to see links
−
If method, look at signature (and for globals)
−
Look at interactions with data and resources
−

17. Breaking Dependencies
Database:

Find the smallest slice of data needed to get
−
functionality to run; everything else null/empty.
Class:

Mock object: just answers back constants
−
Self shunt: object communicates with test case
−
Method:

Build up structures manually, don't rely on
−
complex helper methods

18. Writing Covering Tests
Goal is to determine the current behavior

Reverse of TDD; covering existing functions

Some tips

Test at the boundary values
−
Ensure “golden” or normal values are tested
−
Tests for handled error conditions
−
Correctness is just the behavior of system now

If lucky, can use old requirements docs :)


19. Make changes
Now that area has test coverage, make changes

Use the full TDD cycle for the changes

Run the tests often

Refactor as much as needed

Extract method (create test first)
−
Extract class refactoring
−
Many others...
−

20. References
Beck, Kent. Test-Driven Development: By Example. Addison-Wesley. 2003

Feathers. Michael. Working Effectively with Legacy Code. Object Mentor,

Inc. 2002. http://www.objectmentor.com/resources/articles/
WorkingEffectivelyWithLegacyCode.pdf
Parrish, Alan et al. Ordering Test Cases to Maximize Early Testing.

University of Alabama. 2003. http://www.agilealliance.com/articles/articles/
ExtremeUnitTesting.pdf
Ynchausti, Randy A. Integrating Unit Testing Into a Software

Development Team's Process. Monster Consulting. 2003. http://
www.agilealliance.com/articles/articles/IntegratingUnitTesting.pdf