Byte-Sized Wisdom: Testing
"All software is tested. Some software is only tested in production."
-Armen Stein, Access MVP
Deciding how much to test an application–especially custom software–is not straightforward.
Certain TDD zealots will settle for nothing less than 100% code coverage. That makes sense for the world's most used database, but it's likely overkill for the typical custom business application.
Python-style doc tests are an effective tool for testing pure functions, but they are insufficient to the task of testing complex interdependent business logic or SQL queries.
For truly mission-critical business logic, I like the approach of programming two completely different algorithms to arrive at the same calculation. The more different the algorithms, the better, as you are less likely to make the same mistake in the same way in both places. If the results of the calculations match, then you can be confident that the calculations are correct–assuming you've properly understood the project requirements.
Ultimately, though, there is no absolute right or wrong answer for how much to test an application; it largely depends on the cost of finding bugs in production.
One thing we can say with absolute certainty is that there's no way to completely avoid testing an application.
You either do some testing of your application before delivering it to your client, or your users do all of it after.