Complexity, testing, coverage

Several years ago I was bitten by a bug where my C# unit tests weren't being run because I had accidentally left the public specifier off my test class definition (and therefore NUnit could not see the class). It was easy to fix - I simply added the public keyword. Wondering how many other times I had accidentally done the same thing I decided to write another NUnit test whose job was to use reflection on its own assembly looking for test classes that weren't public. I was pondering this episode again recently while doing some C training. In C (and C++) you don't have reflection. It occured to me that you might be able to use code coverage to avoid this potential problem. If the coverage could separate out the test code from the tested code you could use less than 100% coverage of the test code to help indicate one or more accidentally uncalled test functions. This highlights that test code and tested code are not the same. Test code typically has lots of detail complexity but very little dynamic complexity.