The document discusses strategies for testing legacy code, including: 1. Writing any tests, even quick and easy ones, is better than no tests, as it helps maintain old code with new bugs, hardware/OS, and third party changes. 2. Starting with characterization tests that validate expected failures can help fix complicated algorithms. 3. Writing tests divided by separated tasks and flows, focusing on the main path and avoiding edge cases, can help test legacy code not originally designed for testing.

1. Testing strategies for
legacy code
Alex Soto @alexsotob

2. Alex Soto
Red Hat Engineer
Open Source Advocate
www.lordofthejars.com
@alexsotob
sdfsd

4. What is Legacy Code?
It is myth?
* Code written by another team
* Hasn’t touch for many years
* Your are afraid to touch
* Not have automated tests

5. Old Code Needs To
Be Maintained
New Bugs
New HW OS
Environment (3rd Party)
No Tests

6. Apply Test First
Strategies?
New Features TDD
Automated and Reasonable Fast
Debugging
Optimazing

7. How To Start?
Write Any Test (Quick and Easy)
Broad Better than Narrow
Less tests is better than No Tests
If Existing Flaky Tests (Study and Remove or Mock)

8. Characterization Tests
Really complicated algorithm
Create a test with wrong values, run it, fails and then we fix it

9. Tests By Division
Write test for each separated task/flow
Front-End you are in trouble try to reduce to API level
Focus on Main Path, avoid edge cases

11. Code Coverage
Check what you are missing
You are never gonna have 100%

12. Test Or Debug
When a user found an issue:
* Test means you understand the bug
* Debug useful for understanding the code

13. Refactor Legacy
Code?
Not Testing in Mind
No Tests
So be cautious

14. Sink In