众所周知，Bob大叔是敏捷式开发的发起者与践行者。对于如何保证代码质量，他推崇的是测试驱动开发方式（TDD）。
TDD的实践原则说起来也就是三项，而且很好理解：
- 在编写好失败的单元测试之前，不编写任何业务代码；
- 只要有一个单元测试执行失败，就不再写测试代码，必须将当前的问题解决掉；
- 业务代码恰好能让当前失败的单元测试通过即可，不用多写。
TDD的好处很多，首先就是让开发者对代码的质量具备了充分的信心。一个正式商用的系统一般都会包含数量众多的功能模块，百十来行代码还能顾得过来，到了数千行代码的时候，要想加个功能改个参数难免心里打个小鼓。而完备的单元测试可以避免这种担心，不放心跑一遍单元测试用例，有问题就解决，没问题就继续。
其次是单元测试用例本身就是最好的功能说明文档，这对于协作开发或是代码交接都是最省时间的。在传统的软件开发过程中，总会强调完备而详细的文档，但问题在于文档的编写总是滞后于代码的实现。没有人希望自己看到的是一份过时的文档，都想直接从代码入手来了解系统实现。显然，单元测试用例就是从系统的底层描述了最小粒度的代码实现。
再次就是TDD对于良好设计的倒逼作用。可能一位开发人员要经过很长时间的磨炼才能具备良好的代码设计能力，做到松耦合、正确使用设计模式等。如果遵循TDD开发方式，则非常有助于培养良好的设计能力。因为糟糕的代码实现意味着难以编写单元测试，诸多功能耦合成一个无法测试的大块代码区。这就会促使开发人员思考如何进行分解并且使用设计模式。
当然，敏捷方法大都是说起来简单，但做起来不容易的。对于TDD来说也是如此，它需要开发人员的严格自律与高度认同。即发自内心地认可并在任何时候都坚持原则。最常见到的一个场景就是老板催得急，开发者心想：“哪还有时间写测试代码，赶紧直接做业务实现，等有空了我再补上吧。”。就此小坑就挖成了大坑，又回到我们熟悉的加班-改bug痛苦轮回中。
要想做到在实际工作中不因为各种理由而违背原则，进行刻意的练习是非常有必要的。借用中国人民解放军常说的一句话就是：平常多流汗，打仗少流血。幸好在网络上还是有很多资料可以使用的，卡塔练习就是从武术中借用的一个术语，意即固定的招式。当然，同样的招式练得好的可以飞花逐叶，踏雪无痕；不肯下苦功夫的只能打个酱油跑个龙套了。
资源链接：
http://katas.softwarecraftsmanship.org
http://codekata.pragprog.com