There's a principle in some circles that suggest that the full suite of regression tests be run after each build, or at the end of each iteration, or before each release. Typically when people talk about stuff like that, they don't bother to specify what they mean by "full", or "regression tests", or even "the" (these tests, but no others?), so it's hard to tell whether the suggestion is reasonable or not. When the suggestion is reasonable, it's founded on the idea that there's a risk that there might be an important problem in the code or the data it deals with—a problem that automated regression tests, typically at the unit level, could catch.

That's a nifty notion. I've worked on several projects where certain unit tests are deemed to be very important, and rightly so. Sometimes these tests are simple assertions that the code deals properly with unexpected values or exceptional conditions. That sounds like a good risk management approach to me. But why stop at the unit tests? If there is a risk of a serious problem, why not move such assertions right into the code? Some might argue that this might cause a performance hit, but on systems that can perform billions of simple comparisons a second, that overhead might be quite tolerable next to the risk of some failure.

Critical thinking is a heuristic approach to solving problems caused by us forgetting something or making an invalid assumption. Testing is strongly informed by critical thinking, and so is good unit testing. The best programmers I've ever seen have been great critical thinkers; they programmed like great testers, recognizing that things can be very different from our preconceived ideas. In some cases, they could sometimes afford to put a different emphasis into their unit testing because the product was exceptionally robust, containing important tests within the running code itself. Unit tests are a great way to mitigate certain kinds of risk, but they're not the only way.