题记：正在读《浮现式设计:专业软件开发的演进本质》(荣获第19届Jolt生产力大奖)一书，顺手写下了一点自己的感想与浅见，是以为记。
前几天刚在我的微博上说我在读一本《测试驱动开发》的书，今天在读《浮现式设计》时又遇见了“测试驱动开发”，好友胡研还调侃说现在有需求驱动开发、系分驱动开发、文档驱动开发、模型驱动开发、用例驱动开发、项目管理驱动开发、质量驱动开发等各种驱动开发。开发人员很悲催呀，各种被驱动:-(
回到测试驱动开发上来吧，当然不是测试人员驱动开发人员，而是用测试的思路推动代码的实现，针对的是开发人员一个角色，通过先写测试代码再写产品代码的方式完成开发活动的一种方法。简称TDD。
我个人与作者一样，一直对这个方法持有怀疑态度，也从来没有付诸于实践。我也曾认为测试是一个专业的活动，应由专门的人员（测试工程师）或部门（质量保证部）来实施方能得到更大的收益。本来开发人员就没时间，还怎么去再做测试的活呢？
现在，我依然没有采用这种高级的实践方式，也没能转换到这种思考问题的方式上，但测试的作用我是认同的。
还记得几章前的软件质量中提到的内聚、耦合与冗余吗？
内聚强的类更易于测试。内聚强也是单一职责原则的体现，当一个类只有单一职责时，无论是先构造测试还是后构造测试，测试代码都会简洁高效，同时这种测试代码也可以扮演客户端的角色，测试代码对类的使用方式，其实就是该类交付后客户端代码的调用方式，具有天然的demo功能，也是对文档的有效补充。
耦合度高的对象难于测试。耦合度高的对象，相互之间关系复杂，甚至于牵一发而动全身，测试用例不好构造，不好隔离，出了问题仍然不好分析定位。还要引入Stub、Mock、Fake等额外的手段来辅助测试用例的构造。如果出现这种情况，其实也在某种程度上说明存在设计不当或设计过度的可能，也许要重构了。
测试为检验冗余提供了机会。无论是使用复制粘贴的代码，还是复用并少量修改了前人的代码，还是通过其他途径，随着时间的推移，系统中总会出现更多的易被忽视的冗余，我曾在《架构如何才能抵制熵增》一文中有专门的描述，使用测试，如果出现冗余的测试，很有可能就有冗余的代码，这个是利于检测代码冗余的。
对于测试驱动开发而言，完全具有测试的作用，编写测试，或者考虑如何编写测试，实质上都是以代码的方式在思考。这对代码的可测试性尤其有利。但TDD的实施肯定有一些条件，重要的不是先写测试还是后写测试，也不是纠结于要不要实施TDD，而是把对代码的可测试性的要求作为衡量代码质量的日常指标，从而引导开发人员拥抱测试。这个过程会漫长且煎熬，有人说像面向过程思维转向面向对象思维一样，但转换成功后，一定会有他的价值的。
——欢迎转载，请注明出处 http://blog.csdn.net/caowenbin ——