《测试驱动开发的艺术》是一本由Lasse Koskela著作，人民邮电出版社出版的平装图书，本书定价：59.00元，页数：348，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《测试驱动开发的艺术》精选点评：

　　●书名起的很吓人，但也就是一本入门书啦。重温了教科书版的用例设计，开发和重构原则，以及ATDD的介绍。

　　●单元测试的牛书。

　　●对TDD是什么无感？看这本书可以帮你入门，里面写了个使用TDD的方法开发一个模板引擎的过程。还行吧

　　●书名无力吐槽……可以先把第 10 章开个头再回头看第 9 章，不然太痛苦……

　　●目前在项目中确实在大量实施TDD等单元测试开发, 但目前发现效果不好, 用例开发与测试方法不当. 需要更专业的意见. 在使用TDD过程中, 需要了解与学习所有涉及的技术点, 这样才能更好地将TDD运用与简单使用在具体项目中. 文中的具体技术的TDD测试框架有借鉴意义.

　　●这个书名真是……

　　●2019.29

　　●挺不错的tdd入门书，虽然里面说得技术有点老了

　　●还是实践出真知，再看看书，理论上提高一下，挺好。

　　●很不错的书，有理论有例子，深入浅出。不搞 Java 所以只看了第一部分。博客水平的翻译很影响理解，后面专有名词多了根本就是灾难。几乎所有测试框架 API 都是英文的，“夹具”、“替身”……看着头晕。

　　《测试驱动开发的艺术》读后感(一)：tdd的思想是不分语言的

　　整本书从tdd的概念到例子说明，都是一步一步的来教，从写单元测试，到重构都很细心的讲解。tdd的书籍实在是太少，而这本书对我来说，可以说是对我今后的开发方式都有巨大的影响，就算我不是从事java开发。

　　《测试驱动开发的艺术》读后感(二)：只能说是一本入门的书籍

　　这本书仅仅介绍了大量概念性的内容，却没有比较有用的sample，显得太空洞，指导意义不是很大。测试驱动开发，是一项实践性很强的开发技巧，本书作为一本的测试驱动开发的入门书籍还可以，艺术二字，纯当是哗众取宠吧。

　　《测试驱动开发的艺术》读后感(三)：看还是不看，什么时间点看。用还是不用，什么时间点用。这都是问题

　　久仰TDD和ATDD大名，从此书中得知一二。

　　此书的英文名是Test Driven - Practical TDD and Acceptance TDD for Java Developers，一定要注意是for Java Developers，翻译成TDD开发的艺术确实有些唬人，不过一旦上升到艺术，肯定是有共通的含义。

　　具体到书中总结的TDD和ATDD的基本概念，流程，实践（Practice），甚至教你如何推广和处理来自不同方面的阻力，无疑都是作者多年TDD的经验。其中总结的很多准侧都令人拍案叫绝，深有同感。例如提高设计可测试性的准侧：

　　1. 尽量使用组合（Composition）而非继承（Inheritance）

　　2. 避免使用static关键字，以及Singleton模式

　　3. 隔离依赖（Isolate Dependencies）

　　4. 注入依赖（Inject Dependencies）

　　字字珠玑，十年辛苦不寻常。结合自己的经验来看，真的是一语点醒梦中人。

　　不过回到本书评的标题：看还是不看，什么时间点看。用还是不用，什么时间点用。这都是问题。这才是我最大的困惑，TDD到底适合什么样的开发人员，如果作为菜鸟碰到一个严格执行TDD的Mentor，那肯定是三生有幸，但我们大部分人都是在已有的Legacy代码上跳舞，如何才能做到并去推广TDD呢？如果一个线上运行良久的系统没有很好的覆盖率，我们应该如何补全测试并推广TDD？当然一味的谈论覆盖率是没有意义的，但是从我个人角度来看，虽然修行在个人，但TDD师傅领进门却十分的重要。

　　任重而道远。

　　《测试驱动开发的艺术》读后感(四)：实实在在的TDD

　　读了《测试驱动开发的艺术》，总结一下有以下几个特点：

　　1，名字“误人”

　　这本书的名字有点过于炫了。应该讲这是一本写给Java开发人员的TDD的书籍，谈的更多的也不是艺术，而是实践。所以Java开发者会感觉更加亲切，也会觉得厚实。

　　2，细致

　　在讲解对于特定技术进行TDD实践方面，作者特别细致。从大的方面包括了对于Web组件、DAO、Swing、多线程等等继续TDD的内容。英文原版甚至还包括了对EJB部分。深入到某个专题，作者通过大量代码示例，分析不同情况，逐一阐述。比如讲解TDD数据访问层的时候，作者分别介绍了用纯JDBC，Spring的JdbcTemplate和Hibernate来实现DAO的时候，该怎么样进行TDD。同时也介绍了怎么样直接连接到内存数据库进行集成测试等。可谓无微不至。

　　3，全面

　　说这本书全面，是指它既介绍了TDD的概念，模式，对于特定技术的运用，同时还讲到了ATDD以及相关产品、策略和应用，可以说包罗万象。特别是ATDD部分，相关的中文出版书籍并不多，可以作为一个很好的入门材料，只是没有了介绍TDD那部分深入，却也留给了大家继续探索的空间。

　　觉得有点美中不足的是，本书缺少一个贯穿始终的项目例子。如果有的话，可能读者会更身临其境。

　　单元测试和TDD还是有本质的区别的。对于那些对TDD不是很熟悉的读者来说，本书的第一部分是很好的入门，第二部分则是很好的实践老师。

　　当然，读这本书，并不轻松。跟之前读的几本图灵的书，比如《结网》、《与孩子一起学编程》相比，本书写得略显生涩，缺乏幽默——也许这就叫做严谨？

　　《测试驱动开发的艺术》读后感(五)：评测试驱动开发的艺术

　　读罢《测试驱动开发的艺术》，忽然想起中国传统文化中的“道器之辩”。《易经》曰：形而上者谓之道，形而下者谓之器。中国的传统文化常常是重道轻器，认为道本器末，即道是根本，其他一切是道的外在表现，器是道的从生与从属。这就导致我们常常喜欢把“道”与“器”割裂开来，一味地重视过度抽象的“道”，进而形成一种形而上学的玄幻，使得“道”高高在上，未能落于实处。重道轻器给传统文化带来的缺失告诉我们，“道”与“器”应该是统一的，道是本质，却又必须依赖于器，受制于器。

　　从软件开发的角度来看，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对象，却不再介绍为何要这样编写测试用例，驱动我们进行设计的意图何在。换言之，后面的例子省略了驱动对设计进行推导的过程。这种驱动设计的能力恰好是很多程序员所不具备的。“器”固然重要，但它必须遵循“道”的要义，在其指引下实施。本书内容“道”与“器”兼顾，却将二者割裂开来，未能形成统一的整体，不能不说白璧微暇，略有遗憾。