I asked how and what different debugging techniques, and he gave an example of manual technique to avoid seeing what's going in code ("If a file is not found, I'll try renaming or something like that"). I said, "this is no debugging, its kind of troubleshooting to avoid debugging". He would not agree to it.., then I told him why not write an intelligent program which will do the same thing programmatically ?(well, its kinda behavioral testing), then? well then he was interested in listening... and was ready for few pills of TDD :).
With few examples, It was easy to explain him how TDD can change the way you think about developing software, he already knows it a bit, tries to minimize it through other manual hacks (this is partially because PHP has smattering good debuggers and he works on PHP based server apps).
I told him "debugging happens to be one of those trivial activities which doesn't differentiate you from others" (no big deal, everyone can do it, right?); You need to consider audience attitude for a successful systematic evangelizing :).
TDD, in its real sense-the test first, is one thing that I still find difficult to explain to people; It requires you to give it a shot without unveiling providential "Zen" behind it, somethings you should just try without resisting and put in practice if you find it effective.
Once, I explained TDD to my trainee team at C-SAM, I explained it by example, told them what happens when you don't have tests, made them feel the pain of debugging; then write tests and show what great peace of mind this automatic testing gives.
To sum the experiences on evangelizing TDD:
- To a good programmer explain the benefits of writing intellectual tests rather than idiot debugging every time.
- To a novice, give a real example; mock a bad situation and exhibit how to tackle it with TDD.
- To an amateur, explain how tests are better than manual troubleshooting.
I hope this experiences will find some use and benefits in development.