关于这道题目的完整解答过程，大家可以到Bob大叔的TheBowlingGameKata去下载对应的PPT。
TDD的三项法则
上面的保龄球训练中，我们一直在遵循着TDD的三项法则：
· 在编写好失败的单元测试之前，不要写任何产品代码。
· 只要有一个单元测试失败了，就不要再写测试代码。无法通过编译也是一种失败。
· 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。
遵循着三项法则，我们开发的过程就是下面这五个步骤不断循环、小步迭进的过程：
· 添加测试用例。
· 运行所有测试用例，如果新用例失败了，执行下一步，否则返回上一步。
· 编写产品代码。
· 运行所有测试用例，如果通过，执行下一步，否则返回上一步，直到写出满足测试用例的代码。
· 重构。
· 返回第一步，继续循环。
TDD的优势
TDD带来的最大好处是提高了单元测试的覆盖率。 传统的先写产品代码，再写单元测试，有两个弊端：
· 一方面是由于产品代码已经成型，生米已经煮成熟饭，你再来写，很容易就会陷入思维定式中，起不到发现Bug的作用；
· 另一方面，这往往会让单元测试成为一项政治任务，产品发布前几天，发现单元测试覆盖率不足，来一场全员写测试用例的运动，这样写出来的代码质量肯定不好高。
那么提高了单元测试的覆盖率对产品有什么好处呢？健康的单元测试覆盖率是在90%以上，为什么要那么高？高覆盖率带来的好处主要有以下三点：
· 确定性。每轮迭代我们的产品都会新增不少代码，这些代码对之前的功能有没有影响？如果我们有一套覆盖率达到90%的单元测试，那么我们只需执跑一遍测试用例，如果全部通过，那么我们至少就有90%的把握可以交付。反之，如果覆盖率越低，我们也就越心虚，越需要更多的人力去进行手动验证。
· 让你有勇气重构代码。当你看到糟糕的代码时，你的第一反应是：WTF!!! 接着，你会说，我才不去碰它，万一碰出问题了，还不都是我的锅！ 但是如果你能够确信自己对代码进行的大刀阔斧的修改，不会破坏任何东西，那么你是不是就更有勇气去重构它了？这就是TDD最强大的地方，它让你拥有一套值得信赖的测试，打消你对修改代码的恐惧。Martin Flower在他的《重构》中也指出，完善的单元测试是他进行重构的基石。
· 单元测试即是文档。同事离职了，他之前负责的模块交到了你手上，你要尽快熟悉这个模块的业务逻辑。看文档？程序员写的文章一般都不太容易看，而且文档经常会和代码不同步，代码修改了文档没跟着改的事情经常发生。看源码？看完也不一定知道为什么要这么实现呀。如果这时候有一套非常完整的单元测试，那绝对是所有接手别人代码的程序员的福音！首先，代码不会撒谎，其次，测试用例明确告诉了你这个函数是做什么的，什么输入对应的都有什么预期输出。单元测试就是最好的底层文档，哪个专业人士不想提供这样一份文档呢？
除了提高单元测试的覆盖率，TDD还能够促成良好的代码设计。由于你先写测试代码，你会尽可能的让代码调用起来更加简单方便，这也就促使你去考虑如何更好的设计代码。如果不先写测试，最后很有可能就会出现一个函数里实现的功能过多，或者和其他代码过于耦合而无法测试的情况。
TDD的局限
在学习一项技术时，总是要提醒自己——“没有银弹”，任何技术都有其局限性。然而，由于用TDD的人实在不多，在网上搜了很久，也看不到什么特别有建设性的观点。下面是我找到的一些关于TDD局限性的看法：
· 对开发者有较高要求。要想做好TDD，必须掌握好单元测试、重构等技能，还要能够写出整洁代码，不然如果写出来的单元测试都很糟糕，那只会加重维护的负担。 —— 评论：那我更要用了，这才能显得我技术过硬啊…..
· 习惯的转变。对于一直习惯上来就写代码的程序员，现在要他们先写测试用例，难免会让他们有些不习惯。 —— 评论：这不跟戒烟一个道理么，改掉坏习惯、养成好习惯的过程总是痛苦的，等我练成TDD大法之后，哼哼…
· 过多的测试用例使得构建变得缓慢。 —— 评论：这就要求我们减少没有意义的测试用例了，比如一些简单的get和set方法，就不需要写测试用例啦。
行动起来
回到这篇文章的主题，“如何说服你的同事使用TDD”，首先，你被我说服了么？
如果你的回答是Yes，你被我说服了，你打算开始使用TDD，好，下面我给出一些练习和使用TDD的建议。
1）TDD Katas 训练
先不要急着在工作中去使用TDD，Bob大叔的网站上还有很多跟保龄球训练类似的题目，你可以去练习一下。而且，相同的练习可以反复训练，Bob大叔在他的《程序员的职业素养》里是这么说的：
和习武者一样，程序员应该懂得很多种不同的卡塔，并定期练习，确保不会淡化或遗忘…
真正的挑战是把一个卡塔练习到炉火纯青，你可以窥见其中的规律。要做到这一点可不容易。
下面是Bob大叔推荐的卡塔：
· 保龄球
· 素因子
· 自动换行
Bob大叔的主页上还有很多其他的Kata，大家可以上去探索探索。
2）编程题训练
网上TDD的例子确实有限，但编程训练题却是一大把，很多网站也都收录了许多经典的算法和数据结构的题目，我们完全可以使用TDD来对付这些题，把代码提交上去，如果没有通过，就说明自己的测试用例不全。
使用TDD来对付编程题，非但不会影响你的答题时间，反而让你一小步一小步的完成题目，而不是像以前一样，思考了很久，却一行代码都没写出来。
网上提供在线编程练习的网站很多，我自己现在在用的是LintCode，大家也可以去自己喜欢的网站上练习。
3）面试时使用TDD
面试时，如果面试官让你在纸上写代码，那就给面试官show一下TDD吧，将纸张一分为二，一半写测试用例，一半写实际代码，当然，你可以先写伪码，因为总免不了要重构，全部写完再用实际代码写一遍，交给面试官。
同样的，TDD可以缓解你一行代码都写不出来的紧张心情。
4）运用到实际项目中
实际项目中运用TDD，通常不像做编程题那么轻松，你可能需要使用Mock/Stub之类的东西，不过这些都有现成的代码库，比如Spring就提供了一套很方便的测试库，你只需要花费一点时间了解一下如何使用即可。
如果你有个开明的领导，不妨在做TDD之前跟他说一下，说不定他和你有一样的想法，并且会给你一些支持；如果你的领导看起来并不那么开明，你觉得有很大可能性他会禁止你TDD，那就别告诉他，悄悄执行，如果最后确实有成效，跟他说，并且要求在组内做一次技术分享，如果最后没什么成效，也不要紧，领导看到的只是你测试用例非常完善的代码。
好了，我似乎又走题了，到底“如何说服你的同事使用TDD”，很简单，用实际行动告诉他们！如果你在使用了TDD之后，确实提升了代码质量，降低了代码缺陷率，那么请理直气壮地和他们分享你使用TDD的心得。
TDD是专业人士的选择，它是一项能够提升代码确定性，给程序员激励、降低代码缺陷率、优化文档和设计的原则。对TDD的各项尝试表明，不使用TDD就说明你可能还不够专业。 —— Bob,《程序员的职业素养》
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
