My problem with Martin's article is that his solution isn't a catch all. In fact, testing is aided by the examples he gives. The things he moans about actually

My problem with Martin's article is that his solution isn't a catch all. In fact, testing is aided by the examples he gives. The things he moans about actually reduce the runtime state set of a piece of code by moving it to compile time. It reduces the amount you need to test. With testing, you write code that ensures a certain set of states and, importantly, ensures against the complement of that set. If your compiler can reduce the set of potential states, that means a few things: 1. Less testing code required. This is better because testing code is still code. 2. Catching more errors since it's easier to cover a reduced set of states. 3. You can focus your discipline on higher level problems. Discipline is great. It's even better when not focused on crap a compiler can pick up. Tools are not the 'answer'. Tools are tools. If a tool helps solve problems, it should be used.