Sidetracked by the Reality of Legacy Code

Our test suite fails! For each test, CppUTest compares memory at the start of its execution with memory at its completion and fails if there’s a mismatch. With a bit of probing, we discover the leaker culprit to be either the third-party logging library, rlog, or our WavReader application’s use of rlog. Dealing with the leak isn’t our primary goal. We need a way to move forward.

CppUTest allows us to turn off leak detection, but it’s a highly useful feature that we want to keep. Further, even if we turned off leak detection, the logging code—which appears throughout WavReader—spews messages onto the console every time we run tests. It’s a nuisance. What might we do other than grin and bear it? It’s possible there’s a way to turn off logging without changing the code, but we’re running out of time and need to move forward.

Third-party libraries can create no end of headaches for testing. They might be slow, they might require extensive configuration, and they might have undesirable side effects. When you first start tackling a legacy codebase, chances are you’ll spend a lot of time up front dealing with similar challenges arising from third-party libraries.

One possible solution is to dummy-out a third-party library via linker substitution. For the WavReader application, we will create a library of stub functions for each rlog function we use and link against that library when we build our test executable.

Linker-substitution, or link-time substitution, sounds a lot harder than it is, but it’s a fairly quick process to set up.