posted 15 years ago
Interesting question, Fred.
It's easy to prove that achieving complete coverage for any nontrivial body of code is prohibitively expensive, but don't allow that theoretical limitation to put you off - it is possible to achieve close enough to complete coverage as to make no practical difference (testing "everything that could possibly break" in XP parlance).
I doubt that there's "one true" answer to what level of coverage is appropriate - it will depend upon your particular project. Having said that, with the widespread adoption of automated unit test frameworks these days, I would be disappointed to see any project with less than 90% coverage, and most should be able to do much better than this.
In the typical application, the area that's likely to be hardest to test is normally the view code. Whether this is a practical problem from a testing perspective depends upon how successful you've been at keeping your views "dumb". Assuming that you have managed to keep all your business logic out of the views, then an absence of comprehensive coverage is unlikely to be a big issue.
