In his latest post Mathias Verraes poses the question of how much testing is too much? At what point does testing actually become less useful and how much you really need.

Figuring out how much unit tests you need to write, can be tricky, especially if you are new to Test-Driven Development. Some teams strive for 100% code coverage. Some open source projects even announce their test coverage on their GitHub profiles – as if coverage is an indicator of quality. Coverage only measures the lines of code that are executed by the test suite. It doesn’t tell you whether the outcome of the execution is actually tested, let alone how valuable that test is. Because of that, code coverage of your entire code base is a pretty lousy metric.

He suggests that the "it depends" answer to "how much testing is enough" question just isn't good enough. He puts most of this in the context of TDD (where testing is built-in to the development time) but some of the thoughts could apply to post-code testing as well. He also talks about over-design and how it relates to refactoring with deeper insight. Finally, he talks about a subject not mentioned much in testing articles - when to delete tests.