Selling TDD to the team
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.
"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.
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.
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.
链接地址: http://www.djcxy.com/p/95558.html上一篇: TDD和游戏物理
下一篇: 向团队销售TDD