读罢《测试驱动开发的艺术》，忽然想起中国传统文化中的“道器之辩”。《易经》曰：形而上者谓之道，形而下者谓之器。中国的传统文化常常是重道轻器，认为道本器末，即道是根本，其他一切是道的外在表现，器是道的从生与从属。这就导致我们常常喜欢把“道”与“器”割裂开来，一味地重视过度抽象的“道”，进而形成一种形而上学的玄幻，使得“道”高高在上，未能落于实处。重道轻器给传统文化带来的缺失告诉我们，“道”与“器”应该是统一的，道是本质，却又必须依赖于器，受制于器。
从软件开发的角度来看，TDD的本质思想即为“道”，这其中包括按照意图编程的思想，提高可测试性的设计原则，以及测试的模式与面向对象的基本思想。而“器”则包含对TDD的合理运用，针对不同的用例场景做出的测试手法，以及对测试工具的使用。
本书第一部分《TDD入门》阐述的正是TDD之道。虽然是入门知识，却高屋建瓴地阐明了TDD的真谛。例如本书写道：
在TDD周期中的第一步中，我们会写测试，实际上这并不只是写测试而已，而是在做设计。我们是在设计API，即用来访问新功能的接口。编码之前写测试，我们会自然地考虑新代码的调用方式。……测试先行的编码方式会促使我们站在代码用户（开发人员）的角度考虑，设计出更易用的API。
很多开发人员并不愿意接受TDD的开发方式，认为这种先写测试后编码的方式既别扭而又浪费时间，原因就在于他们没有真正体会这种测试驱动设计的好处。TDD最重要的一个字眼儿就是drive（驱动），事实上，这种驱动力正是所谓“按照意图编程”的重要思想。
意图编程，顾名思义，就是说写代码时先假设其他部分代码都已经存在了（即使事实并非如此）。使用这种编程方法时，我们可以把注意力集中在能有的，而不是已经有的东西上。使用意图编程，我们能让代码读起来更流畅，容易理解和使用，也能使代码清晰地表达出自己的本意，而不会过于强调实现细节。
个人认为，本书第一部分给出的邮件模板子系统的范例更贴近开发真实，却又不至于晦涩难懂。作者在选择范例上的匠心独运，使得本书既具有很强的实践指导意义，又不至于陷入复杂的业务需求和技术细节中。范例给出的第一个测试、伪实现以及重构的手法，都是自然而然的TDD过程，而不是为了写作本书生拉硬拽，东拼西凑，有着强烈地雕琢痕迹。若能在阅读过程中，比照着这样的过程动手实验，相信能够获得更大的提高。
从本书的第二部分开始，就迈入了TDD“器”的部分。之所以说是TDD之“器”，在于它介绍了针对特定技术应用TDD的内容，这其中包括对Web组件、数据访问、多线程、Swing代码的测试驱动开发。在讲解的过程中，作者还介绍了大量用于这些特定技术应用TDD的工具或框架，例如JspTest、EasyMock、MockObjects、HSQLDB、Jemmy、Abbot等。这些都是Java平台下常用的支持TDD的有力工具。本书的第三部分则着重介绍了ATDD（验收测试驱动开发），包括对用户故事的介绍，验收测试的特征与实现，ATDD的过程以及相关工具Fit。这在许多介绍TDD的书籍中都是不多见的内容。
这两部分内容给出了许多贴近开发真实的例子，提出了许多卓有成效的测试方法。这些内容如此地实用，涵盖的知识如此地全面，基本上可以解决我们在企业开发中进行TDD可能遇到的问题。事实上，这些内容大多数都可以说是TDD实践过程中的拦路虎，尤其是针对表现层和多线程技术的TDD方法，大多数开发人员都缺乏这方面的知识，甚至因为这样而放弃TDD。本书极具实践指导意义的阐述弥补了这一空白。遗憾的是，本书介绍的内容主要针对Java开发人员，因而提及的工具也都基于Java平台，对于其他平台下的开发人员而言，无疑削弱了几分价值。
本书还有一点不足就是“道”与“器”的不统一。前面提到，本书的第一部分开篇名义，用极简洁的语言道明了TDD的本质。然而本书的第二部分与第三部分，几乎只停留在TDD方法和工具的使用上，而忽略了测试对于设计的驱动力。书中的例子仅仅给出了如何完成测试用例，如果建立Mock对象，却不再介绍为何要这样编写测试用例，驱动我们进行设计的意图何在。换言之，后面的例子省略了驱动对设计进行推导的过程。这种驱动设计的能力恰好是很多程序员所不具备的。“器”固然重要，但它必须遵循“道”的要义，在其指引下实施。本书内容“道”与“器”兼顾，却将二者割裂开来，未能形成统一的整体，不能不说白璧微暇，略有遗憾。
本文转自wayfarer51CTO博客，原文链接：http://blog.51cto.com/wayfarer/490946，如需转载请自行联系原作者
