A good system will run as many of the tests as practical at system startup, not just in QA.  In other words, build the tests right into the product and ship it with the tests present and operable.  This may not always be possible due to size and memory constraints, but an extra second or two of run-time startup is well worth it if all of the tests can be run all the time.  Overall, this means that the tests should integrate into the main application framework from the beginning, though they need not or want to use advanced subsystems such as memory management, debugging, etc.

Test management, configuration, execution, and output should be run through a test controller that can coordinate test activities in the application.  This is important during both the QA cycle and in production, as the test manager can report consistent test results to the daily build and test system, and it can gracefully handle test failure in production.

The test manager configuration should allow for various groups of tests to be run, potentially at different levels of detail.  The latter is most useful if extensive tests are very time consuming and therefore undesirable in production or at a developer's desk, but still desirable for regression or QA troubleshooting.  The ideal test manager configuration is via test file that lists one test are per line with an associated test level.  

It is important not to modify the test manager for each newly added test, so all tests should be dynamically discovered and managed at runtime (though a header file may have to be edited with each new test controller).  In addition, each modules tests should probably have their own mini-controller that manages that suite of tests in terms of execution order and detail level.  It is this mini-controller that registers with the main test controller and gets called if a named entry is present in the configuration file.

The quality of the unit test code should closely approximate that of the main modules, following the same coding standards, otherwise there will be two modes, sloppy for tests and slightly less sloppy for main modules; writing high quality code all the time will raise overall quality.