Why writing tests for legacy code is a good thing

Pavol Rajzak on August 31, 2017

You are working as a software developer with application that was developed when hoola-hooping was still cool and unit testing was considered to ... [Read Full]
markdown guide

Nice post. I'm a big fan of unit testing. And I really like working with legacy code. "Working effectively with legacy code" by Michael Feathers is one of the best references about this topic.

I'm looking forward to your other posts.


Hi Pavol. Thanks for post. You have mentioned static analysis tool. Can you advice a good setup to measure progress of technical debt resolution?



First of all, if you have large codebase which hasn't been measured for technical debt I would recommend first setting up SonarQube to have a good baseline for later measurements. It doesn't make sense to setup quality gates that would fail a build, since this can be done only when the codebase is cleaned up.

So, setup SonarQube, create first analysis and then try to make it a habit within development team to check for technical debt periodically (e.g. after every sprint, or even more frequently). SonarQube is quite good in defining the most critical flaws, so it's always good to start with that. Sometimes it gives a false-positives, but these can be easily resolved (within SQ or in code, for example as annotation in Java).


Awesome post! Right after "Unit test the s#&% out of it." I knew it was going to be a good one 😁. I'll be looking forward for more of your posts.


Thanks! That motivates me even more to write more posts :)


It's the only way I've seen to refactor legacy code with confidence and without breaking anything.
Are you planning on writing a series about this subject?


I've written so far two follow-up articles about this topic:

Feel free to leave comments or questions! :)


Actually, I can, since this is my current assignment. I will prepare some posts! :)

code of conduct - report abuse