Selling TDD to the team [closed]

Question

I have been doing TDD for the past 3 years. We were a small company, and we had very solid support for most aspects of the agile process from management. Everyone on the development team was sold on the process. And thus, the upfront investment it usually takes to build fixtures was accepted knowing it would pay off along the way. (Code that starts an http server, code that populates sql databases before tests, etc). Documentation mostly happened in the tests and help requests were usually presented in the form a failing test.

Now I moved to a bigger company, and while management is supportive of the Agile process, teammates are a mixed bag, some of them see it useful, some of them do it because of management and some don't see the value. It's been a challenge to convince people to spend some time building fixtures or to convince a team member the best way for me to help him if he took the time to write a failing test.

So what do you think is the best way to sell TDD to a hesitant teammate? The objections are usually : 'It's an unneeded cost', ' we can always write tests after the fact for parts that are important', 'it's a buzz word, teams pick it up and then it falls to the side as the heavy grind begins' etc.

Answer 1

"the best way to sell TDD to a hesitant teammate"

You can't. Don't waste time "selling".

Instead, invest time in "proving".

Just do it. Be successful. When people ask what the secret of your success is, then reveal the TDD. Not before.