Unit testing with C/C++: Lessons, what to remember?

Question

Unit testing with C/C++: What do you teach people who either did not do unit testing before or come from Java/Junit?

What is the single most important lesson / thing to remember/ practice from your point of view that saves a lot of time or stress (especially regarding C/C++)?

Answer 1

1. Unit tests have to run automatically on every checkin (or, unit tests that are written then forgotten are not unit tests).
2. Before fixing a bug, write a unit test to expose it (it should fail). Then fix the bug and rejoice as the test turns green.
3. It's OK to sacrifice a bit of "beauty" of a class for easier testing (like provide public methods that should not really be public, but help your testing/mocking).

Answer 2

I'd like to rephrase ripper234 and add some more rules:

1. Every module (usually DLL project) should have separate UT project. All UT classes should be friends to all the DLL classes they need to access private methods/members from.
2. If you want to change the module - first change the UT. Make sure both the DLL and its UT compile, link and the UT run without crashes and failures before check in. There is no need to run all UT for all modules before each check in - this is a waste of time.
3. All UT should be automatically rebuild in the nightly build along with all DLLs. All UT and modules should compile and link during the build.
4. All UT should be automatically run after the night build succeeds and the results should be summarized.
5. The summary with all UT results should be posted to the developers and if there are any failures or crashes they should be corrected ASAP.

Answer 3

Single most important lesson: A test is better than no test.

Answer 4

A unit test case should only test one thing.

I see it much more often in C/C++ compared to C# and Java that unit test cases test entire workflows.

Perhaps it is because most C/C++ xUnit frameworks require several steps to register a testcase, so the temptation to just add a few lines to an existing testcase when adding a new feature is higher.

Answer 5

In the case of dealing with legacy code base with no tests, you will most probably start (as I had to) with functional tests that use a unit test framework for implementation. Don't be alarmed - your code is so interconnected that it's probably impossible to write proper unit tests. Don't be complacent, either - once functional tests are in place, you need to refactor so that true unit tests are possible. Your code will be better for it!

Answer 6

I'm against all of these recommendations for automatically granting friendship to test classes...

Personally I prefer to focus on the following to allow me access to the insides of a class that I need to test:

1. Rely on the public interface of the class where possible; sometimes this means extending the public interface slightly to allow for easier testing. Don't fight these extensions too much but also don't let them drive your design too much...
2. Consider adding a monitoring interface which can be used by 'real' code as well as test code to enable monitoring of the code under test. (I still surprise myself with how often this is a really good part of the design process).
3. Consider providing access to some parts of the class to derived classes via a 'protected interface' and derive a 'testable' version of the class in question that can then be instrumented and tested.

In summary, I much prefer to see designed in test points rather than a blanket friendship with a test class. Of course the former is harder to do than the latter but, IMHO, results in better code AND better tests.