不是艺术，而是实实在在的实践
本文同时发在我的博客上：http://www.cnblogs.com/yuyijq/archive/2010/12/08/1900789.html
在北京的天气正在一天比一天冷的11月底我收到了这么一本标题带有艺术的书籍。我本来对技术书籍标上艺术或之道或之美的标题很厌恶。而最近各个出版商却对这样的标题很热衷，不过厌恶归厌恶，这本书还是给我带来了一丝丝温暖。
目录
翻开目录我就发现，中文出版社将这本书标题定为艺术实在是掩盖了这本书散发出浓浓的“实践”的气息。没看到任何的艺术，只看到满眼的具体实践，而且与日常工作联系十分的紧密。
第一章
第一章作者用不大的篇幅介绍了一下TDD的概念，这部分并没有任何出彩的部分，大部分以TDD为名的书籍都有这样的介绍，不过本书不同的是介绍了ATDD（验收测试驱动开发），这在大部分TDD的书里是没有的。敏捷软件开发中度量进度的标准就是实际交付物，并不是你用单元测试驱动出来了多少代码。那么如果我们用验收测试驱动出来代码，然后让验收测试变绿，这算不算呼应敏捷软件开发的进度度量呢？所以很多TDD的书对ATDD的忽视也算一种缺憾。
第二、三章
不管你看了多少TDD的书，如果没有看到真实的示例，你还是觉得这些都是浮云。没有代码就开始测试？我测什么，怎么测？作者用了两章的篇幅用TDD的方式来编写了一个功能很弱但也算完备的模板引擎。并在字里行间不断的提醒我们：测试->实现->重构的步骤，一次又一次的警告我们不要贪多，重构要小步进行。从这点，让我回忆起有多少次Rollback一整天的工作，仅仅就是因为违背了这些看似简单的规则。
第三章对我的触动更为深刻，在公司里每当我们无法对一个用户故事划分出清晰任务（完成这个故事采用的先后步骤），我们就先要进行Spike，然后我们就可以划分出任务了，从而也可以估计出比较合理的点数。不过作者所阐述的依照测试列表工作而不要根据任务列表倒是没有尝试过，有机会可以尝试一下。
在2.6节作者写了个简单的性能测试，不过却在我心中起了不小的波动。性能这东西是个非常难以捉摸的怪物，考虑早了可能根本抓不着瓶颈到底在哪儿，考虑迟了可能为时已晚。如果我们跟用户谈好可接受的性能，然后我们编写一个性能测试，这个测试就像一个警报一样，只要性能一突破这个防线，警报就拉响，我们就要查查是我们刚刚编写的哪段代码影响了我们的性能。嗯，这也许是个很可行的方法。
在阅读第二、三章的时候，如果你能打开你最顺手的IDE，和作者一道使用TDD驱动出这个模板引擎，我相信你将收获颇多。不过你可能要嚷道，我们的项目可比这复杂得多，我们的项目需要几十人月，有多少多少代码。嗯，我知道你们的项目很复杂，但是复杂的项目也是非常多简单的代码有机的组合而成。在你实现一个功能的时候你不要想着你的项目有多复杂，你只需要关注你当前的测试就可以了。这也是作者在这两章里时常提醒的原则。
第四章
怎么样，跟着作者使用TDD的方式完成了这么个小“模板引擎”，是不是觉得单元测试很简单？如果你这么想那就上钩了，要写单元测试特别是写好单元测试并不那么简单。要让自己的测试有模有样，还是有很多模式和原则需要遵守的。作者如是在短暂的实践之后马上奉上了一章TDD的概念与模式。
在这一章不仅仅介绍了“夹具”、“测试替身”、“基于状态的测试”等基本名词概念，还给出了很多实用的技巧，比如三角法，就像几何中的三点确定一个平面，我们也用几个测试来固定一个产品代码。嗯，还有不能不提的测试驱动基本原则：1）、绝不跳过重构（如果没有重构这一环节，即使你有很完备的测试，还是会生产出很多糟糕的代码，因为使用测试驱动我们总是想尽快通过测试，甚至很少去思考设计上的问题） 2）、尽快变绿 3）、出错后放慢脚步（记得曾经在哪里看到过，敏捷就是慢的艺术，在写代码时切忌跑得过快，贪多，我们要做到每一步都胸有成竹，如果出错了不要紧，说明你走得太快了，放慢你的脚步）。
如果你曾经试图过给已经写就的代码加单元测试，你会发现总有一些东西在阻碍你：继承（我们此时只关注子类，但父类很多的东西带来了累赘）、静态（static关键字修饰的东西或单件模式是一种紧耦合，很难使用测试替身替代，也很难模拟）。
和开发产品代码一样，测试驱动也有很多很有用的模式，铭记这些模式会让你事半功倍。
最后作者用很短的篇幅介绍了怎么在遗留代码上进行工作，如果你没时间阅读《修改代码的艺术》这本书，这里是个很不错的总结。
第五、六、七、八章
虽然前几章已经很精彩了，但是碰到有些具体场景你可能还是束手无策，发现前面几章的内容还是有点不够用。嗯，后面作者用了四章来阐述测试驱动在具体场景中如何工作：在web开发中如何和控制器一起工作？如何验证渲染的视图是不是正确的？如何使用测试驱动开发出DAO层？对于DAO层我们还是一如既往的使用模拟对象么？如果写集成测试我们该怎么做？有的时候我们经常会发现测试随机失败，这太让人气馁了，其实你是遇见了不可预测的问题，作者也准备了一章篇幅来介绍这些问题：与时间相关的问题，与多线程相关的问题。第五章介绍了web开发，第八章确实桌面开发了，如果你能给你的桌面应用写出很好的单元测试，说明你的桌面应用中业务逻辑也很好的与界面解耦了，这不是我们一直追求的么？呵呵。
第九、十、十一章
嗯，本书极具特色的一部分来了：验收测试。在这一部分讲解了用户故事，验收测试的工具验收测试的策略。实际上第三部分作者不仅仅是在讲解验收测试驱动开发，更是在谈论敏捷的开发方式，如果不想投入大把时间去看用户故事、敏捷计划等相关的专门书籍，本部分是一个很好的概览。
后记
就谈到这里吧。翻到书的封面发现英文标题Test Driven practical TDD and Acceptance TDD for Java Developers历历在目。哦，总算明白了出版社为什么要抛弃“实践”这个原名，披个艺术的马甲。
在北京的天气正在一天比一天冷的11月底我收到了这么一本标题带有艺术的书籍。我本来对技术书籍标上艺术或之道或之美的标题很厌恶。而最近各个出版商却对这样的标题很热衷，不过厌恶归厌恶，这本书还是给我带来了一丝丝温暖。
目录
翻开目录我就发现，中文出版社将这本书标题定为艺术实在是掩盖了这本书散发出浓浓的“实践”的气息。没看到任何的艺术，只看到满眼的具体实践，而且与日常工作联系十分的紧密。
第一章
第一章作者用不大的篇幅介绍了一下TDD的概念，这部分并没有任何出彩的部分，大部分以TDD为名的书籍都有这样的介绍，不过本书不同的是介绍了ATDD（验收测试驱动开发），这在大部分TDD的书里是没有的。敏捷软件开发中度量进度的标准就是实际交付物，并不是你用单元测试驱动出来了多少代码。那么如果我们用验收测试驱动出来代码，然后让验收测试变绿，这算不算呼应敏捷软件开发的进度度量呢？所以很多TDD的书对ATDD的忽视也算一种缺憾。
第二、三章
不管你看了多少TDD的书，如果没有看到真实的示例，你还是觉得这些都是浮云。没有代码就开始测试？我测什么，怎么测？作者用了两章的篇幅用TDD的方式来编写了一个功能很弱但也算完备的模板引擎。并在字里行间不断的提醒我们：测试->实现->重构的步骤，一次又一次的警告我们不要贪多，重构要小步进行。从这点，让我回忆起有多少次Rollback一整天的工作，仅仅就是因为违背了这些看似简单的规则。
第三章对我的触动更为深刻，在公司里每当我们无法对一个用户故事划分出清晰任务（完成这个故事采用的先后步骤），我们就先要进行Spike，然后我们就可以划分出任务了，从而也可以估计出比较合理的点数。不过作者所阐述的依照测试列表工作而不要根据任务列表倒是没有尝试过，有机会可以尝试一下。
在2.6节作者写了个简单的性能测试，不过却在我心中起了不小的波动。性能这东西是个非常难以捉摸的怪物，考虑早了可能根本抓不着瓶颈到底在哪儿，考虑迟了可能为时已晚。如果我们跟用户谈好可接受的性能，然后我们编写一个性能测试，这个测试就像一个警报一样，只要性能一突破这个防线，警报就拉响，我们就要查查是我们刚刚编写的哪段代码影响了我们的性能。嗯，这也许是个很可行的方法。
在阅读第二、三章的时候，如果你能打开你最顺手的IDE，和作者一道使用TDD驱动出这个模板引擎，我相信你将收获颇多。不过你可能要嚷道，我们的项目可比这复杂得多，我们的项目需要几十人月，有多少多少代码。嗯，我知道你们的项目很复杂，但是复杂的项目也是非常多简单的代码有机的组合而成。在你实现一个功能的时候你不要想着你的项目有多复杂，你只需要关注你当前的测试就可以了。这也是作者在这两章里时常提醒的原则。
第四章
怎么样，跟着作者使用TDD的方式完成了这么个小“模板引擎”，是不是觉得单元测试很简单？如果你这么想那就上钩了，要写单元测试特别是写好单元测试并不那么简单。要让自己的测试有模有样，还是有很多模式和原则需要遵守的。作者如是在短暂的实践之后马上奉上了一章TDD的概念与模式。
在这一章不仅仅介绍了“夹具”、“测试替身”、“基于状态的测试”等基本名词概念，还给出了很多实用的技巧，比如三角法，就像几何中的三点确定一个平面，我们也用几个测试来固定一个产品代码。嗯，还有不能不提的测试驱动基本原则：1）、绝不跳过重构（如果没有重构这一环节，即使你有很完备的测试，还是会生产出很多糟糕的代码，因为使用测试驱动我们总是想尽快通过测试，甚至很少去思考设计上的问题） 2）、尽快变绿 3）、出错后放慢脚步（记得曾经在哪里看到过，敏捷就是慢的艺术，在写代码时切忌跑得过快，贪多，我们要做到每一步都胸有成竹，如果出错了不要紧，说明你走得太快了，放慢你的脚步）。
如果你曾经试图过给已经写就的代码加单元测试，你会发现总有一些东西在阻碍你：继承（我们此时只关注子类，但父类很多的东西带来了累赘）、静态（static关键字修饰的东西或单件模式是一种紧耦合，很难使用测试替身替代，也很难模拟）。
和开发产品代码一样，测试驱动也有很多很有用的模式，铭记这些模式会让你事半功倍。
最后作者用很短的篇幅介绍了怎么在遗留代码上进行工作，如果你没时间阅读《修改代码的艺术》这本书，这里是个很不错的总结。
第五、六、七、八章
虽然前几章已经很精彩了，但是碰到有些具体场景你可能还是束手无策，发现前面几章的内容还是有点不够用。嗯，后面作者用了四章来阐述测试驱动在具体场景中如何工作：在web开发中如何和控制器一起工作？如何验证渲染的视图是不是正确的？如何使用测试驱动开发出DAO层？对于DAO层我们还是一如既往的使用模拟对象么？如果写集成测试我们该怎么做？有的时候我们经常会发现测试随机失败，这太让人气馁了，其实你是遇见了不可预测的问题，作者也准备了一章篇幅来介绍这些问题：与时间相关的问题，与多线程相关的问题。第五章介绍了web开发，第八章确实桌面开发了，如果你能给你的桌面应用写出很好的单元测试，说明你的桌面应用中业务逻辑也很好的与界面解耦了，这不是我们一直追求的么？呵呵。
第九、十、十一章
嗯，本书极具特色的一部分来了：验收测试。在这一部分讲解了用户故事，验收测试的工具验收测试的策略。实际上第三部分作者不仅仅是在讲解验收测试驱动开发，更是在谈论敏捷的开发方式，如果不想投入大把时间去看用户故事、敏捷计划等相关的专门书籍，本部分是一个很好的概览。
后记
就谈到这里吧。翻到书的封面发现英文标题Test Driven practical TDD and Acceptance TDD for Java Developers历历在目。哦，总算明白了出版社为什么要抛弃“实践”这个原名，披个艺术的马甲。
有关键情节透露
