新書推薦:
《
养育不好惹的小孩
》
售價:HK$
77.3
《
加加美高浩的手部绘画技法 II
》
售價:HK$
89.4
《
卡特里娜(“同一颗星球”丛书)
》
售價:HK$
87.4
《
伟大民族:从路易十五到拿破仑的法国史(方尖碑)
》
售價:HK$
188.2
《
古今“书画同源”论辨——中国书法与中国绘画的关系问题兼中国画笔墨研究
》
售價:HK$
132.2
《
《日本文学史序说》讲演录
》
售價:HK$
72.8
《
无尽的海洋:美国海事探险与大众文化(1815—1860)
》
售價:HK$
99.7
《
治盗之道:清代盗律的古今之辨
》
售價:HK$
122.1
|
編輯推薦: |
软件工程领域泰斗、极限编程之父Kent Beck力作,荣获第14届Jolt大奖,畅销不衰
不仅以案例的形式生动地呈现了测试驱动开发的原则和方法,而且详尽地阐述了测试驱动开发的模式和最佳实践
|
內容簡介: |
本书是测试驱动开发领域的开山之作,由软件工程领域泰斗、极限编程之父Kent
Beck撰写,荣获第14界Jolt大奖,10余年畅销不衰,具有里程碑意义。书中不仅以案例的形式呈现了测试驱动开发的原则和方法,而且详尽地阐述了测试驱动开发(TDD)的模式和最佳实践。
本书共32章,分为三大部分。第一部分(第1~17章)从简单问题入手,介绍了TDD的概念、优势与设计方法,再逐步深入到解决复杂问题的方式;细致讲解了如何在编写程序代码前编写自动化测试,如何先塑造一个设计再通过重构逐渐添加设计上的构思,如何为更复杂的逻辑创建测试等。第二部分(第18~24章)讲解用xUnit创建测试的实例,介绍如何利用xUnit框架创建自己的测试用例,便于高效地进行测试。第三部分(第25~32章)介绍TDD的设计模式,包括部分经典的设计模式以及如何将这些模式与TDD相结合,还介绍了重构的方法,以及TDD中的特殊问题等。本书从始至终贯穿了两个TDD项目,展示了如何轻而易举且卓有成效地编写优质代码的技术。
|
關於作者: |
肯特·贝克(Kent
Beck)软件工程领域泰斗、测试驱动开发理念提出者、极限编程之父,在设计模式、测试驱动开发和极限编程领域有很深的造诣,被誉为“计算机软件行业最具创造性才能的领导者之一”和“Java领域最具影响力的10位技术领袖之一”。他为软件行业的发展做出了卓越的贡献。早在1993年,他就与UML之父携手倡导软件开发的模式定义,推动了软件开发模式在软件行业的发展;更突出的贡献是,他提出并推动的极限编程方法学,以及他与Erich
Gamma共同打造的JUnit工具,引发了敏捷开发的热潮。他著述颇丰,撰写了《解析极限编程:拥抱变化》、《实现模式》等多本经久不衰的经典著作,这些著作被翻译为多种文字,在世界范围内广泛传播和流行。
白云鹏 资深软件开发工程师,对软件过程有深刻理解,曾在微软(美国)总部参与多个项目的全程发布。研究方向是:软件过程改进、测试新技术应用和软件算法分析与设计。出版有《软件测试人员(Java·高级)》等著作。
|
目錄:
|
译者序
前言
致谢
引言
第一部分 货币实例
第1章 多币种货币实例
第2章 简并对象
第3章 定义相等性
第4章 实例变量私有化
第5章 法郎的自白
第6章 相等性再定义
第7章 美元和法郎
第8章 制造对象
第9章 正在进行的times方法
第10章 有趣的times方法
第11章 万恶之源
第12章 总算谈到加法了
第13章 到达我们的预期
第14章 变化
第15章 多币种货币
第16章 总算谈到抽象了
第17章 货币回顾
第二部分 xUnit实例
第18章 走进xUnit
第19章 设置主线
第20章 后续的清理
第21章 计数
第22章 处理未通过的用例
第23章 好美妙的测试套件
第24章 xUnit回顾
第三部分 测试驱动开发的模式
第25章 测试驱动开发模式
第26章 红条模式
第27章 测试模式
第28章 绿条模式
第29章 xUnit框架下的模式
第30章 设计模式
第31章 重构
第32章 掌握测试驱动开发
附录A 影响图
附录B 斐波那契数列
后记
|
內容試閱:
|
“可运行的简洁的代码”是Ron
Jeffries关于测试驱动开发(TDD)目标的精辟概括。有一大揽子理由能够说明,可运行的简洁的代码是值得实现的目标:
它是一种可预测的开发方式。你会知道自己何时可以完成,而不必担心因缺陷而拖得太久。
它会给你全面认识代码的机会。如果你草率地采用了自己最初的想法,那就再也没有时间来考虑另外更好的想法了。
它让使用我们软件的用户生活变得更加美好。
它使成员之间相互信赖。
它本身的编写过程也让人感觉很棒。
但我们如何才能得到简洁的可运行的代码呢?很多因素使我们与简洁的代码渐行渐远,甚至导致代码无法运行。其实,不用为我们的担心浪费太多笔墨,这样做就可以:使用自动化测试驱动开发,一种叫做“测试驱动开发(简称TDD)”的开发方法。在测试驱动开发中,我们:
仅当自动化测试失败的时候才编写新的代码。
去掉重复的部分。
这是两项比较简单的原则,但这会产生出一个或一组技术方面复杂的行为准则,例如:
我们必须参考每次修改后代码运行状况的反馈,逐渐完成设计。
我们必须自己编写测试,因为我们不能指望其他人编写测试。
我们的开发环境必须对细微的修改迅速做出响应。
我们的设计必须遵从高内聚、低耦合的原则,这样便于实施测试。
那两项简单的原则预示了编程任务的先后顺序:
1. 红色指示条—编写一个无法工作的简单测试,当然,这个测试起初甚至都无法通过编译。
2. 绿色指示条—迅速使测试工作起来,这个过程可谓想方设法,甚至不择手段。
3. 重构—去掉单纯由于使测试工作起来而产生的重复部分。
红色指示条-绿色指示条-重构—此乃TDD的经典三部曲。
先假设这样的编程方式是成立的,进一步讲,这种方式可使代码缺陷的密度降低,还可以使所有相关人员对工作主旨若网在纲。如果这样的话,只在测试失败时才需要编写的代码还有其社会意涵:
如果可以将缺陷的密度降到足够低的话,那么,质量保证人员的工作状态就能够变被动为主动。
如果可以尽可能地减少令人不悦的意外发生,那么,项目管理人员就能够非常精确地估算出日常开发工作所需的人手。
如果可以将技术讨论的主题构思得足够清晰,那么,软件工程师就可以亲密无间地合作,而非拉锯式地工作。
同样,如果可以将缺陷的密度降到足够低,那么,我们每天都可以发布带有新功能的软件,这样会与客户建立新的业务往来。
诚然,这个理念并不复杂,但其背后的动机又是什么呢?为什么一位软件工程师要插手编写自动化测试以外的工作呢?为什么一位软件工程师能够给出高屋建瓴的设计却以细微的步伐前行呢?勇气使然。
勇气(Courage)
测试驱动开发是一种在编程过程中管理担忧的方式。这不是杞人忧天之虑,而是合理的担忧,但是否合理的问题是很难从一开始就看出来的。如果疼痛的自然反应是喊“停!”,那么担忧的自然反应则是喊“当心!”。当心历来是好事,但担忧却有不少其他的副作用:
担忧使你举棋不定。
担忧使你疏于交流。
担忧使你回避反馈。
担忧使你郁郁寡欢。
这些作用对于编程都是无益的,尤其是在编写有难度的程序时。因此,你该如何面对困难的局面呢?并且:
尽快开始具体地了解一些东西而不是试探。
更加清晰地交流而不是闭口不言。
找出具体的有用的反馈而不是回避。
克制负面情绪。
把编程想象成使用曲柄从一口井中摇上一桶水的过程。当水桶不太大时,自由旋转的曲柄还不错。当水桶比较大并且装满水,再把水桶提上来的时候,你就会感到累了。你需要一个在转动曲柄的间隙能够使你休息的棘齿装置。越重的桶,就需要棘齿装置的齿越密。
测试驱动开发当中的测试就像棘齿装置的齿。一旦测试运行起来,你就知道它会这样子运行下去了。比起测试坏掉的情况,你已经朝着一切运行如仪的目标又迈进了一步。现在,还可以使下一个,下下个和再下一个测试运行。以此类推,越是棘手的编程问题,每个测试的覆盖面要越小。
阅读本人著作《Extreme Programming
Explained》的读者会注意到描述极限编程(XP)和测试驱动开发在语气上的差异。TDD与XP有所不同。XP会要求你必须准备这样那样很多东西。但TDD却没有那样地泾渭分明。TDD很明确地知道,设计和现实之间肯定存在很多差异,还告诉了你控制这种差异的方法。“我要是用一周时间做书面上的设计,然后用测试驱动代码如何?这算是TDD吗?”当然算啦!这就是TDD。你意识到了设计与现实之间的差异,并且有意识地掌控它。
即便如此,大多数学习TDD的人发现他们的编程行为被永远地改变了。测试感染(Test
Infected)是Erich
Gamma发明的用来描述这一转变的说法。你可能会发现自己比以前会写更多的测试,会发现使用更小的步伐推进要比曾经自己想象的要合理。另一方面,一些软件工程师学习TDD后保留了他们原有的编程行为,在一些特殊的情况下,当常规的编程方法不奏效的时候,他们才拿出TDD救急。
当然存在不能仅仅(或者根本不能)由测试来驱动的编程任务,例如,软件安全性和并发问题,使用TDD去一板一眼地证明这两方面与需求的吻合度就会显得捉襟见肘。尽管事实上软件的安全性本质上依赖于无缺陷的代码,但也依赖于使软件变得安全所使用方法的人为判断。微妙的并发问题是不能通过运行代码就能可靠再现的。
一旦你阅读完这本书,你应该准备:
从简单的地方着手。
编写自动化测试。
通过每次重构添加一回设计上的构思。
本书分为三部分。
第一部分,货币实例—一个典型的使用TDD编写的示例代码。这个示例是数年前我从Ward
Cunningham那里得到的,而且在多币种算法的例子中使用过多次。这个例子会使你学到在编码前就编写测试,并且逐渐地完成设计。
第二部分,xUnit实例—一个为自动化测试开发的框架,测试包含反射和异常且拥有比这更复杂逻辑的例子。这个例子还会给你引入xUnit架构,这是众多面向程序员的测试工具之关键所在。在第二个例子中,你会学到用比前一个例子中更小的步伐来工作,包括那种计算机科学家们所钟爱的自我提醒式的念叨。
第三部分,测试驱动开发的模式—包括了决定可以编写哪些测试这样的模式,如何使用xUnit编写测试,以及精选的设计模式和在示例中使用的重构方法。
我将示例描述为结对编程的场景。如果你喜欢在闲逛前先查看地图的话,那么也许你要直接去看第三部分的那些模式,并且尝试其中所举的那些例子。如果你倾向于只是闲逛,事后再去看看地图你都到过哪里的话,那就试着逐个阅读书中的示例吧,当你想知道某个技术的更多细节时可以查阅这些模式,把这些模式作为参考。本书的几位审阅者说,当他们启动编程环境,输入代码并运行他们所读到的程序时,最大的收获来自于这些示例之外。
关于这些示例需要注意的一点是,多币种的计算和测试框架这两个例子显得比较简单。但却也存在着(我曾经见过)使用复杂,不雅且愚蠢的方法解决相同问题的情况。我本来可以选择其中某个复杂、不雅、愚蠢的方法来给本书以“真实感”。但是,我的目标是编写可运行的简洁代码,希望你的目标也是如此。在开始这些被认为非常简单的例子之前,花费15秒钟想象一下,一个所有代码都简洁明了,不存在复杂解决方法的编程世界,仅有复杂的问题需要认真思考。那么,TDD完全可以帮助你得偿所愿。
|
|