Good entry on unit testing tips over at /dev/null. Definitely agree with the last point: "Remember that unit tests are but a small piece of the quality puzzle". One of the common mistakes junior developers make is dismissing the idea of unit testing because "it doesn't handle system integration issues" (for example).
I find the first point about having a control case interesting. I've never used this idea in my unit testing experience, but it sounds similar to the idea used in aircraft fly-by-wire control systems. They typically have several systems running in parrellel that have been written by different developers (Airbus calls this "multiversion programming") - for fault tolerance at a hardware level, and to validate that the outputs are in agreement across all systems. These types of systems are architected for "Byzantime fault tolerance", protecting against the possibility of misleading signals (or output values in the case of unit tests) from components confusing the system. The point is, once you introduce the idea of a control and you find anomalies, you take on the additional burden of having to decide if it is the control or the component under test that is actually broken. I am not sure our non-mission critical application warrants this level of investment, but for the right applications I can see this being a useful technique.