Adding unit tests to legacy code

Question

Have you ever added unit tests, after the fact, to legacy code? How complicated was code and how difficult to stub and mock everything? Was the end result worthwhile?

Answer 1

If you are planning on refactoring the legacy code then creating those unit tests is a must. Don't worry about mocking or stubbing - worry about testing the inputs and outputs of the system so that your changes or refactoring efforts don't break current functionality.

I won't lie to you, retrofitting unit tests to legacy code is difficult - but it is worth it.

Answer 2

Yes, and it's generally painful. I've often ended up having to write integration tests instead.

The book The Art of Unit Testing has some good advice on this. It also recommends the book Working Effectively with Legacy Code; I haven't read the latter yet, but it's on my stack.

EDIT: But yes, even minimal code coverage was worthwhile. It gave me confidence and a safety net for refactoring the code.

Answer 3

Michael Feathers book "Working Effectively with Legacy Code" is an entire book covering this topic. Michael states that it is often too difficult to introduce tests for legacy code because it is not structured to be testable. What I got out of the book the most was a couple of patterns named "Sprout functions" and "Sprout classes". A sprout function is one that encapsulates the change that you need to make in the code. You then unit test these functions only. The sprout class is the same idea except the new functionality is contained in a class.

Answer 4

The best way, I have found, is to incrementally add the unit tests, not to just jump in and say we will now unit test the application.

So, if you are going to touch the code, for bug fixes or refactoring, then first write the unit tests. For bugs unit tests will help prove where the problem is, as you can duplicate it.

If refactoring, you will want to write unit tests, but you may find that the test is impossible to write, so you may need to find a high level, that calls the function that will be refactored, and unit test that part. Then, as you refactor the offensive function, write your tests so you can ensure that it is operating as it should.

There is no easy way to do this.

This question may help with more suggestions. http://stackoverflow.com/questions/748503/how-do-you-introduce-unit-testing-into-a-large-legacy-c-c-codebase

Answer 5

One alternative to unit tests, also introduced in Working effectively with legacy code is characterization tests. I had interesting results with such tests. They're easier to set-up than unit tests as you test from point than can be tested (called seam). The drawback is that when a test fails, you have less hint about the location of the problem as the area under test can be much larger than with unit tests. Logging helps here.

---

A unit test framework such those of the xUnit family can be used to write characterization tests.

In such tests, written after the facts, assertions verify the current behavior of the code. Unlike unit tests, they do not prove that the code is correct, they are just pinning down (characterizing) the current behavior of the code.

The process is similar as the TDD one,:

• write a test for a portion of code
• execute it - fail
• fix the test from the observed behavior of the code
• execute it - pass
• repeat

The tests will fail if you modify the external behavior of the code. External behavior of the code ? sounds familiar ? Yes it is, here we are. Now you can refactor the code.

Obviously the risk depends on the coverage of the characterization tests.