Yet another unit testing / code coverage question. Is my approach sane?

This is yet another Unit Testing question. I'm trying to draw knowledge from a number of places regarding how to proceed, and I wanted to bounce my current understanding off of the collection of experts here.

assume a project for which all dependencies except opengl funkiness are statically linked (except the c run time)

My current understandings so far:

1. It is ok to make unit tests that only test the public interface of classes because ultimately the class is the unit that is most sane to test. Problems ca开发者_如何学运维n be hunted down from there (inside the offending class), and a class that is too complicated to debug, requiring unit testing of its internal structures, is a good candidate for having it broken up. This practice makes it possible to write unit tests in its own project, from a Visual studio perspective.

2. A code coverage tool, like CoverageMeter, is installed in the main project, and given its own build configuration, like test instead of debug. This will place the metrics inside the object code for the external "viewer" tool to get metrics.

3. At the same time, the main application is built as a library in the Test configuration, so that the external Unit Test project uses the object code to run its tests. At the same time further, the CoverageMeter code is included in the library that the Unit Test project uses for its run, making the coverage metrics measure how much code is being exercised in unit tests.

4. With a testing configuration made separate from release or debug, placeholder libraries can be used to break dependencies like opengl.

My questions really are: Is this pie in the sky stuff? Do I have my understandings right? can I actually do the first sentence of 3, is that how I would get the Unit test code to run the object code build in the main app project, or is there another way?

Am I insane? I am open to any criticism. Thanks in advance for your time.

UPDATE: So it looks like I have the right idea of what to exercise in my unit tests, but I'm concerned about 3. Is my understanding of those components correct?

Thanks for your responses. Its good to get feedback! This will be my first big project, and I'm trying to understand all of the pieces involved. I appreciate the pointers!

Josh

---

I test everything but private methods, since anything else can be called from outside the class, and it would be helpful to ensure that if someone else calls my function it won't cause problems for them.

If they are also testing calling my code then if they make an assumption that is wrong, we can know quickly that a recent change broke something.

Update: I would distribute any tests for public functions with the distribution and internally the rest of the tests. If people are going to write against my API then unit tests serve as a good source of documentation, to show what I expect to happen, and how I expect to treat invalid parameters.