enlightening!

Thanks for the excellent article. I come at this as a semi-professional developer who aspires to high standards. I have tried to embrace using unit testing, if not outright TDD, and thought there was something wrong with me whenever I decided to go ahead and write the code first. I have also sometimes found it awkward to write certain kinds of test, and also invested time debugging and updating the tests to conform to the latest changes in the code. Nothing is more horrible than spending an hour trying to get your tests to pass when your manual test in a web browser is working fine. And still, lo and behold, you can test the hell out of everything from end to end and still introduce bugs.

There is surely some benefit to automating the kind of things we do manually, whatever they are. If I want to test whether some refactoring has broken something, the computer can run 100 test assertions against the code a lot faster than I can by hand, doubtless a Good Thing. It is very reassuring to see nothing but green lights -- hopefully not a false sense of security.

The other good takeaway from the TDD gospel is this: it forces you to think about what a piece of code is supposed to do before you write it. It seems self-evident, but it helps to be coerced into thinking about your API in a disciplined way before your fingers touch the keys.

So, as with so many things, it's the extremes that are dangerous. No testing, bad; no keystrokes at all without testing, bad; judicious use of automated testing, good.

Sure, but the point is that you do not need to do TDD in every little component of your project.

Many projects are not even testable with automated tests because they depend on external things that you can't mock.

For those that are testable, the cost of test versus the benefits is often arguable.

I suppose the presumption is that the external dependencies have already been tested to death, so our own testing has to be a little higher-level.

But yeah -- we agree.