Selling TDD to the team

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

simple -- maintainability. TDD gives you the ability to make changes, and see where those changes affect the rest of the code. The larger the code base, the more imperative it is that there be tests to validate any new changes.

correctness. Although tests can themselves be broken, eventually they reach a point where they make sure the components are doing what they are supposed to. The better the developer, the faster that is.

another advantage is that TDD informs the design of the components in the system. If you are trying to test something, and the test is too complicated, it probably means you need to break the problem down into smaller parts...

to sell it to people, you say that in the long run it makes adding new features cheaper, and reduces the risk of breaking existing functionality. So it reduces cost.

Answer 2

"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.

Answer 3

I think Joel's post explains very well why testing is A Good Thing™.

I don't think he ever uses the phrase "TDD", but it's got some great info.

Answer 4

For the hesitant teammate, be patient, wait for an opportunity, then pounce. In software development there will undoubtedly be an problem where TDD would have prevented or mitigated the problem. Be on the lookout for such an opportunity. Work with him/her to create a test(s) that should have been developed from the beginning. However, make sure you craft your message in such a way to not embarrass your teammate.

Answer 5

I agree with S. Lott, you can't "sell" them you need to show the value.

One of the most effective ways to do that is with pair programming. Granted you have another "sell" problem convincing people that pairing is an effective approach, but after some time you may convince/convert a developer or too.

TDD was a tough concept for me initially, but now I can't imaging programming any other way.