Retrofitting unit tests for legacy code

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

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.

KISS

kiss2 Can’t stress this enough: keep your tests simple. You’ll notice you end up with 80% boilerplate code, setting up mocks, creating test objects, etc. When that test fails you’ll have no clue why was it there in the first place.
This happens a lot with legacy codebases, where stagnant code tends to get quite coupled and messy. If you plan to write a big mega test to cover every use case with a single test, the day it fail you’ll quickly know it’s not production ready but you’ll have no clue why is that.

Mock layers

If you have a project divided in components (even the ugliest legacy code tends have some sort of layers separation, even if coupled with other components) try to create mocks for a whole layer of the application (I ended up with a complete mock of a DB, for example). This will help you in the long run to isolate troublesome modules. layers

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.

Advertisements


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s