How do you introduce unit testing into a large, legacy (C/C++) codebase?

Question

We have a large, multi-platform application written in C. (with a small but growing amount of C++) It has evolved over the years with many features you would expect in a lar

Answer 1

Make using tests easy.

I'd start with putting the "runs automatically" into place. If you want developers (including yourself) to write tests, make it easy to run them, and see the results.

Writing a test of three lines, running it against the latest build and seeing the results should be only one click away, and not send the developer to the coffe machine.

This means you need a latest build, you may need to change policies how people work on code etc. I know that such a process can be a PITA with embedded devices, and I can't give any advice with that. But I know that if running the tests is hard, noone will write them.

Test what can be tested

I know I run against common Unit Test philosophy here, but that's what I do: Write tests for the things that are easy to test. I don't bother with mocking, I don't refactor to make it testable, and if there is UI involved i don't have a unit test. But more and more of my library routines have one.

I am quite amazed what simple tests tend to find. Picking the low hanging fruits is by no means useless.

Looking at it in another way: You wouldn't plan to maintain that giant hairball mess if it wasn't a successful product. You current quality control isn't a total failure that needs to be replaced. Rather, use unit tests where they are easy to do.

(You need to get it done, though. Don't get trapped into "fixing everything" around your build process.)

Teach how to improve your code base

Any code base with that history screams for improvements, that's for sure. You will never refactor all of it, though.

Looking at two pieces of code with the same functionality, most people can agree which one is "better" under a given aspect (performance, readability, maintainability, testability, ...). The hard parts are three:

• how to balance the different aspects
• how to agree that this piece of code is good enough
• how to turn bad code into good enough code without breaking anything.

The first point is probably the hardest, and as much a social as an engineering question. But the other points can be learned. I don't know any formal courses that take this approach, but maybe you can organize something in-house: anything from two guys worting together to "workshops" where you take a nasty piece of code and discuss how to improve it.

---