Just wait until he has to write a system with several hundred web services that have been documented to perform in a very precise manner given particular data sets, and have hundreds of customers who have integrated to that API, and absolutely required that there be no variance in the output in the API, or there (extraordinarily expensive) system integration will fail, at great costs to their business systems.
I'm not saying TDD makes sense everywhere, but being able to confirm that your 3000+ continuous integration tests all passed green before shipping a new version to all of your customer is a huge way to avoid embarrassingly predictable bugs. (Leaving, of course, the opportunity to ship the embarrassingly non-obvious bugs)
And, honestly, it's not clear that he was opposed to TDD, as he was opposed to being constrained to having to write huge test frameworks during the exploratory phase of code development, in which you may want to have a bit more freedom to write/discard while you feel out requirements/solutions.
What you described having tests, not doing TDD. That is, it's important to have those test cases verifying that your APIs still work, but that doesn't mean you have to design the APIs by writing tests, as opposed to designing by thinking about what you actually want to achieve.
Fair point. I was more referring to his comment here: I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development--a better strategy is to focus on competence and good design.
Unit tests are useless for ensuring that a web service API works, they are too low level. You're supposed to be testing only the "units", aka classes or groups of methods.
I stand corrected twice. Probably just goes to show that a non-(current)developer should spend 30 minutes of research on a topic before commenting on a thread.
I'm not saying TDD makes sense everywhere, but being able to confirm that your 3000+ continuous integration tests all passed green before shipping a new version to all of your customer is a huge way to avoid embarrassingly predictable bugs. (Leaving, of course, the opportunity to ship the embarrassingly non-obvious bugs)
And, honestly, it's not clear that he was opposed to TDD, as he was opposed to being constrained to having to write huge test frameworks during the exploratory phase of code development, in which you may want to have a bit more freedom to write/discard while you feel out requirements/solutions.