Agile Software Development Principles, Patterns,and Practices 第6章读书笔记

第六章 保龄球（TDD开发）

这章主要通过TDD方式来开发一个保龄球积分系统，以下是开发过程中结合工作过程中对TDD以及单元测试的一些心得体会。

　　1. 有助于设计简单清晰而易用的接口。因为总是先有测试代码，才编写实现代码，意味着总是从使用者的角度设计接口，只有简单易用的接口才方便测试时调用，所以我几乎是“被迫”去努力设计简单易用的接口，因为我就是第一个使用者。

　　2. 模块切分的足够小但是模块间保持极低的耦合度。为了方便测试，我总是尽力把重复的逻辑剥离出来，单独构建模块进行测试;并且尽量减少模块间的耦合，保持模 块相对独立和功能完备。如果模块过大，或者模块间强耦合，写测试用例与代码时就会困难重重，笨重复杂。因为总是先写测试代码，眼前的利益高于一切，将来的 实现代码必然要迁就目前测试的需要。于是，我又“不知不觉”设计出小粒度模块，且模块间耦合度低的实现。

　　3. 肆无忌惮的重构。因为有测试用例和测试代码作担保，我终于能够从小心翼翼心惊胆战的重构中解脱出来，只要是更好的实现和设计，我都愿意尝试，管它呢，反正 多跑几遍测试就知道重构的结果如何了。可以说，测试驱动开发鼓励代码的不断进化，即使测试已经全部通过，也可以通过大胆重构来改进设计与实现。尽管此时是 否还需要再重构见仁见智，至少提供了一个可能，我是很喜欢这一点。

　　4. 测试代码是“活”的软件文档，它硬性规定了实现代码必须满足的需求，达不到就报错。传统的文本文档比之就苍白无力多了，“应该”，“必须”，这些字眼对程 序员有多少约束力?而且测试代码总是能与实现代码保持新鲜同步，传统文档写完后经常被上传服务器束之高阁，很少人问津，随着开发组内人员的变动，往往最后 就湮没在服务器的故纸堆之中了。