测试驱动开发
当前位置:首页 > 计算机网络 > 软件工程/开发项目管理 > 测试驱动开发
出版社:中国电力出版社
出版日期:2003-8-1
ISBN:9787508314013
作者:Kent Beck
页数:248页
内容概要
Kent Beck是软件开发方法学的泰吉、XP的创始人，长期致力于软件工程的理论研究和实践，并具有讲授XP的丰富经验。作为软件业内最富创造性和最有口碑的领导人之一，Kent Beck极力推崇模式、极限编程和测试驱动开发。他现在加盟于Three Rivers 研究所，是多部畅销书如《Smalltalk Best Practice Pattrns》、《解析极限编程拥抱变化》和《规划极限编程》的作者，并且是超级畅销书《重构——改善既有代码的设计》的特约撰稿人。
书籍目录
PrefaceAcknowledgmentsIntroductionPART I:The Money ExamplePART II:The xUnit ExamplePART III:Patterns for Test-Driven DevelopmentAfterwordIndex
编辑推荐
在本书中你将学会由简到繁解决复杂任务，在编码前先写出自动测试程序。每次实现一个新的构思，通过不断的重构有机地扩展原有的设计，创建用于更复杂逻辑的测试，包括reflection和esceptions，用模式判定写什么测试，用许多面向程序员的测试工具的核心结构——xUnit创建测试。
作者简介
本书从头到尾跟踪介绍了两个TDD项目，描述了程序员容易上手又能大大提高工作质量的技术。在涉及TDD最有特色的模式和重构后面都附有例子。通过将侧重点放在灵活的方法和快速开发的策略上，肯定能激发读者接受这些未被充分利用但功能强大的技巧。本书是Kent BecK先生的最新力作，在亚马逊网站上持续热卖，是Addison-Wesley出版公司著名的大师签名系列图书之一。
图书封面
发布书评
精彩书评 (总计8条)
-
关于测试驱动开发有很多谬论和误解。关于这点的澄清永远没有尽头，就像任何其他的方法一样，所谓正解和误解都是相伴而生的。而本书是总结这个在开发社团里面实践经验的开山之作，关于他的评价是，误解的不想读，不误解的也不愿意读，前者是因为已经有误解的心态对于这种小题目而言，实在经不起这种误解的心态去读，对于后者，因为已经在beck主持的论坛里面讨论实践了多年，不愿意再去读。这本书产生就已经决定了他名声在外，暗受冷遇的命运。但是我要说的是，这本书确实值得读。像前一个读者的评论，他可以改变一些观点，如果你真的愿意用心读的话，另外关于测试驱动开发的相关信息也可以从这个链接去看看，http://zh.wikipedia.org/wiki/%E6%B5%8B%E8%AF%95%E9%A9%B1%E5%8A%A8%E5%BC%80%E5%8F%91。关于这本书的读的方法有几个小建议：1.加入tdd论坛和人讨论；2.坐在键盘前，边看边Learn by doing -
1。 刚开始看的时候，很纳闷，难道作者在教学校生作文啊？那个小那么小的一步前进，我们还要不要写软件了？后来看到了这样一句话，there is no right step size, now and forever，我明白了，作者只是给出了一个方法，至于实施过程的具体细节，每个人要根据自己的情况和软件的情景来设定的。2。测试驱动开发的本质是什么？我觉得先写test case很大程度上是帮助我们更清楚的认识问题，当问题清楚明确，又具体的定义，那么解决问题就只是一个流程了，所以，大部分时候不是问题很难解决，而是问题很难被具体的定义，写case可以帮我们解决一部分这个问题。3。现实中的开发如何借用呢？现实中我们可以一直在用书上提到的方法，只是没有明确的给出定义或者没有明确的按照上面流程来罢了。在现实的开发中，我们也是先设计，然后做详细规划，觉得差不多了，就开始写代码，然后边写边改，。。。最后完成，然后写个测试用例来测试，pass，一切ok。这么做最可能的问题是，当我们完成某个功能的时候，位于兴奋中，我们可以就不愿意思考出有效充分的用例来测试我们得程序，我们总觉得：不会有问题的。这其实是个心理问题了，人当然不愿意否定自己，而写完程序之后写测试用例就是否定自己（怀疑有问题才写测试嘛），所以写完程序再写测试case是不太合理锝。以后还是要先写测试case再写程序，当然未必想作者说的那么详细4. 写完一段程序就思考一会，想想是不是有问题。这点尤其有用，我的经验显示，这对于程序的改进很有价值。，下星期继续读，完了再写 -
思想很好，传统开发模式下顾问、项目经理管需求，资深开发者、设计者进行分析设计，程序员负责开发，一方面带来项目管理、项目风险诸多问题，另一方面也造就大量"不负责任"的程序员，妨碍程序员综合能力的提升、思维和视角的拓展。TDD下程序员直接面对需求、用例，参与设计，以测试为主题进行驱动，能够比较好的解决这些矛盾，在思想指导层面的确意义重大针对复杂业务系统、基础框架进行设计，思维在流程、模块、架构、整体与细节之间穿梭时，常常遇到很多问题理不清思路，利用TDD的方式对这种状况很有帮助TDD的主要思想和运用方式讲解起来比较简单，开始几章用例子来讲解就安排的很不错，非常通俗易懂。后面弄出来这样那样的模式感觉比较牵强，如果作者将自己多年的TDD实践经验进行总结、整理，针对各个点配合一些实际场景进行讲解说明，比使用模式的方式要好。另外一点在实际项目中，如何从一开始在团队中实施TDD流程，以TDD思想进行分析以及任务分解，督促团队成员以TDD进行开发，这一整体面的东西书中并没有讲到，是一个缺憾
精彩短评 (总计33条)
-
测试驱动开发的经典入门书，学习极限编程的必读书之一。 -
为了重构成功，先学会写单元测试。
喜欢上单元测试，因为重构的爽快感。 -
居然读过 -
看不懂，还以为是中文的。 -
必读啊，而且有些例子可以做一下。Dive into Python里面也有例子，不错，建议实践一下。 -
TDD应该是设计的王道，无论大小，最近在做tldcache，因为需要对compiler的理解，本来已经写完了的cache，却因为和compiler的框架不付，无法找到intercept point -
还没看，听说是好书~~ -
读到最后有点看不懂了 -
非常棒的一本书，测试驱动是一本关于开发方法学的书。绝对让你有全新的认识！大师的作品值得一读！ -
其实这本书讲述了一个神话。 -
kent书，读起来，总是感觉没有Bob大叔和Martin Fowler的来的畅爽...，不过，作为Junit的作者和XP的创始人，这本书也是实践敏捷和TDD的必读书目之一。 -
英文原版影印, 质量不错. 书本生也非常好. 软件开发人员必看. -
TDD的经典书籍，看看大师怎么编程的吧。 -
这本书，页数不多，但是内容很丰富，虽然我不用java开发，使用c++开发，但是动手练习下money的例子，在结合后面的理论部分，感觉获益匪浅。 -
测试驱动开发不是万能的，但是如果你觉得TDD能真正提升你的编码效率与质量，那就去使用。如果你是个经常靠撞大运编程的程序员，那么什么开发方法都拯救不了你，TDD尤甚，甚至会成为你的理由。 -
经典 -
挺不错的 -
里面的知识让我获益好多 -
已经绝版了，只能买到复印版 -
看了前几个章节，过于琐碎了。 -
彻底改变了编程体验的一本书 -
这本书还不错，是全英文版，可以锻炼自己的阅读能力。 -
所在的项目一直采用TDD来开发，这算是自己看的第一本TDD相关的理论书籍。前面货币的例子还行，对于从未接触过TDD的人有帮助。后面总结性的模式那几章，很有启发。 -
测试驱动的布道书，但靠这本书掌握测试驱动还不够 -
TDD 适合程序初学者，是一种职业素养。
当程序员成熟起来后，TDD就显得腐朽不堪了。翻译的真是好 -
这本书没有太多涉及团队管理、流程管理方面，对主要思想和运用方法讲解起来比较简单。开始几章用例子来讲解就安排的很不错，非常通俗易懂。后面弄出来这样那样的模式很牵强，倒不如作者将自己多年的TDD实践经验进行总结、整理，针对各个点配合一些实际场景进行讲解说明，比使用模式的方式要好。另外一点在实际项目中，如何从一开始在团队中实施TDD流程，以TDD思想进行分析以及任务分解，督促团队成员以TDD进行开发，这一整体面的东西书中并没有讲到，是一个缺憾 -
可惜当当的包装好烂 -
书不厚但是触及了测试驱动的精髓 -
结合最近写junit，感觉测试有那么点感觉了 -
值得一读，重要的是理解思想，而不能生搬硬套。 -
读的是中文版... -
测试驱动开发，理念很清楚，但如何在项目中落实，比如GUI的测试用例如何完成，测试用例占用的工时，如何说服老板去多投入人力和时间 -
很不错的一本书，书切入的角度很好。很有实践价值。