People definitely take test-driven-development to unhelpful extremes, yes. I recall a couple of developers who were obsessed with it, guilt-tripping others into 100% coverage (as if that were possible!).
In the days of ye olde Extreme Programming dogma, test-driven development supposedly gave license for developers to code in the most direct way possible to make the tests pass, which often resulted in some pretty awful code indeed. So that's an extreme.
Although, for a platform on which a business depends, TDD is pretty damn good.
Call me lazy, but I reserve my tests for bits of code that are really complex, like certain custom algorithms that can't be easily visually verified, and go easy on the bits that can be easily verified with a code inspection. My 2c!
People definitely take test-driven-development to unhelpful extremes, yes. I recall a couple of developers who were obsessed with it, guilt-tripping others into 100% coverage (as if that were possible!).
In the days of ye olde Extreme Programming dogma, test-driven development supposedly gave license for developers to code in the most direct way possible to make the tests pass, which often resulted in some pretty awful code indeed. So that's an extreme.
Although, for a platform on which a business depends, TDD is pretty damn good.
Call me lazy, but I reserve my tests for bits of code that are really complex, like certain custom algorithms that can't be easily visually verified, and go easy on the bits that can be easily verified with a code inspection. My 2c!
I do agree that 100% coverage is too much and can be a time waste. In many cases even TDD is not suitable for the development process.
His point, however, was "no tests at all are needed if you think carefully when you code".
...and "lazy people are those who want tests"