/ ARTICLES

Should I write tests for legacy code if there's no time for refactoring?

I found this collection of opinions about what to do when faced with legacy code in a tight schedule very interesting.
Should we write tests for the code even though we know we will not be able to refactor it in the short/medium term. Is it a waste of time or are we contributing to contain the mess that old code can often degenerate into? What if to test it we need to take a step back in terms of code quality?

I hate having to deal with big chunks of untested legacy code, because it makes me feel I loose control of what I am doing. In those cases answering simple questions like "will this new feature work with no side effects ?" or "how long will it take to do a change in that part of the code" make me have to either say I don't know, or have to deal with varying degrees of certainty. Given how murphy's law works, I prefer to have my code tested and to have a high degree of confidence in it.

Also, I happen to think Uncle Bob's "Boyscout rule" to be a great rule to follow when doing professional programming.

Here is the article:

http://arstechnica.com/information-technology/2014/06/should-i-write-tests-for-legacy-code-if-theres-no-time-for-refactoring/

What do you do in these situations ?

rui

Rui Pires

Working as a professional full time remote developer from the Azores since 2011.

Read More