Retrofitting unit tests for legacy codePosted: October 23, 2009
|Some time ago I saw a discussion at google test mailing list which made me ask myself how would I go about implementing TDD for a legacy codebase project, based from previous experiences. I came up with a list, open to discussion, which may be useful as a guideline for someone in this situation.|
Start with integration tests
Integration tests are ugly and won’t give you a lot of information about what went wrong when something does, but you have no chance of running real unit tests in non-injectable code.
Use the integration tests as a safenet to refactor the critical methods, those which will be changed the most during the projects lifetime, which leads me to the next point;
Test as you refactor (or implement new functionality)
If you plan to stop the business and write a kabillion tests for your legacy codebase you’re out of luck. Not only you’ll fail because the lack of value but you’ll spend weeks writing tests and never see the ROI – you’ll quickly grow tired.
With integration tests in place take your time to write real unit tests as needed, that is when you implement new functionality or when you plan to refactor something – which should be to implement new functionality or to fix a bug.
Have a team commitment
If you’re working on your own or with a team, make it mandatory to run the tests for each commit. Even better if you can implement a continuous integration server.