Today I started using for the first time some unit testing libraries for C and C++ (CUnit
http://cunit.sf.net/ and CppUnit
http://cppunit.sf.net/ , respectively). What I'm still unsure about is how those fit in build and test process.
For example with Java and JUnit, the compiled classes are compiled in a separate directory, and running the tests simply involves adding those to the classpath and setting the Main class to JUnit which will run the tests for you.
With C and C++ though, you effectively have to change your one and only available "main" function, either by using a macro in place or by compiling a different "main.c" in it's place. Because of this, you have a choice of making the unit testing code part of your released binary, or recompiling your code with different macros or settings to run it in "test mode". But if you run unit testing on a differently compiled version of the code, there's still a small chance that this change would make the code different enough to make the testing inconclusive.
On top of that, many unit testing libraries are LGPL. If you don't know, LGPL has a clause that forces your software license's to allow for reverse-engineering of the interface between the code and the LGPL library. Not only this is a big "no no" for commercial code, but on top of that the "interface" would touch so many parts of your test code (and thus your actual code) that by extension it would imply that you would allow all your code to be fully reverse-engineered. That's why released code cannot contain anything related to those unit testing libraries, introducing the risk that the code reacts differently between the unit tested version and the released one. Arg!
Maybe recompiling the code to run unit testing (maybe even including code coverage) is not as much of an issue as I think it is and is actually commonplace. I guess as long as there is some kind of smoke testing on the ready-for-release executable, combined with thorough unit testing on the "test version", it should be sufficient.