TDD says "no line of product code is written until there is a unit test that fails for it". I'm just pointing out that there is a spectrum of practicality in TD

TDD says "no line of product code is written until there is a unit test that fails for it". I'm just pointing out that there is a spectrum of practicality in TDD. Our automated regression tests for graphics routinely require humans to re-verify every single screen capture because a single pixel may render slightly differently with some other change and there is no algorithm to determine "is this artifact objectionable to humans". Tests are good, but they are not a panacea. As for the "proper exceptions" or error codes or what not. That always drove me NUTS to see that. The first line of the function is `if (foo == null) throw new ArgumentNullException("foo")` -- do I really need to write a unit test for that? Furthermore, static analysis tools tell us when your public interface (including exception types we may throw) changes, that is code reviewed too. Writing `AssertThrows(typeof(ArgumentNullException)...` is just a waste of time. Again: this is not an argument about whether tests have merit or not. All the author (and I) are saying, at the core of our argument, is that write tests when it makes sense to write tests. He's also going a step further to say "it makes sense to write tests less frequently than TDD nuts would have you believe". I may or may not agree with him, but I'm going to publicly denounce that belief simply because I'd rather developers write too many tests than too few.