注册 | 登录读书好,好读书,读好书!
读书网-DuShu.com
当前位置: 首页出版图书科学技术计算机/网络软件工程及软件方法学有效的单元测试

有效的单元测试

有效的单元测试

定 价:¥59.00

作 者: Lasse Koskela 著
出版社: 机械工业出版社
丛编项: 华章程序员书库
标 签: 计算机/网络 软件工程/开发项目管理

购买这本书可以去


ISBN: 9787111483434 出版时间: 2014-11-19 包装: 平装
开本: 16开 页数: 200 字数:  

内容简介

  本书分三部分,共9章。第一部分(第1~3章)主要阐述测试的目的与原因,并分析作为常用工具的测试替身的作用。第1章先从整体阐释测试先行所带来的价值,以及各种对测试和测试质量的影响。第2章定义了如何才能写出优秀的测试。第3章谈及现代程序员最基本的工具之一——测试替身。第二部分(第4~6章)的目标是帮助我们更好地识别并修复测试代码中的坏味道。第4章展示破坏测试可读性的坏味道。第5章继续对破坏可维护性的测试提供建议。第6章涉及有关脆弱或不可靠的测试坏味道。第三部分(第7~9章)涉及Java程序员在编写测试时随时可能碰到的话题。第7章介绍可测的设计的定义与作用。第8章探讨JVM语言的共生,以及如果用另一门语言来测试Java代码。第9章专门讨论对构建进行加速的问题。此外还包括两个附录,附录A介绍了使用JUnit编写测试的入门知识。附录B探讨通过JUnit的API来扩展其内置功能。

作者简介

  Lasse Koskela,资深敏捷技术实践专家、敏捷教练、培训师、顾问和程序员,具有数十年计算机程序设计和开发经验。他精通多种编程语言,尤其对Java、Ruby、C/C++有独到见解,热衷于编程和追逐前沿技术,在程序设计、软件工程、项目管理等多个领域颇有建树。目前他主攻开源项目,帮助企业提高生产力,而且经常在世界各地的会议上发表演讲。除本书外,他还著有《测试驱动开发的艺术》。

图书目录

序言
前言
致谢
第一部分 基础
第1章 优秀测试的承诺 2
1.1 国情咨文:编写更好的测试 3
1.2 测试的价值 3
1.2.1 生产力的因素 6
1.2.2 设计潜力的曲线 8
1.3 测试作为设计工具 9
1.3.1 测试驱动开发 9
1.3.2 行为驱动开发 11
1.4 小结 12
第2章 寻求优秀 13
2.1 可读的代码才是可维护的代码 14
2.2 结构有助于理解事物 16
2.3 如果测试了错误的东西就不好了 17
2.4 独立的测试易于单独运行 18
2.5 可靠的测试才是可靠的 21
2.6 每个行业都有其工具而测试也不例外 22
2.7 小结 23
第3章 测试替身 24
3.1 测试替身的威力 25
3.1.1 隔离被测代码 26
3.1.2 加速执行测试 27
3.1.3 使执行变得确定 27
3.1.4 模拟特殊情况 28
3.1.5 暴露隐藏的信息 29
3.2 测试替身的类型 30
3.2.1 测试桩通常是短小的 30
3.2.2 伪造对象做事不产生副作用 31
3.2.3 测试间谍偷取秘密 32
3.2.4 模拟对象反对惊喜 34
3.3 使用测试替身的指南 35
3.3.1 为测试挑选合适的替身 35
3.3.2 准备、执行、断言 36
3.3.3 检查行为,而非实现 37
3.3.4 挑选你的工具 38
3.3.5 注入依赖 39
3.4 小结 39
第二部分 目录
第4章 可读性 42
4.1 基本断言 43
4.1.1 示例 43
4.1.2 该对它做点儿什么 44
4.1.3 小结 45
4.2 过度断言 46
4.2.1 示例 46
4.2.2 该对它做点儿什么 48
4.2.3 小结 50
4.3 按位断言 50
4.3.1 示例 50
4.3.2 该对它做点儿什么 51
4.3.3 小结 51
4.4 附加细节 52
4.4.1 示例 52
4.4.2 该对它做点儿什么 53
4.4.3 小结 54
4.5 人格分裂 55
4.5.1 示例 55
4.5.2 该对它做点儿什么 56
4.5.3 小结 58
4.6 逻辑分割 59
4.6.1 示例 59
4.6.2 该对它做点儿什么 61
4.6.3 小结 63
4.7 魔法数字 64
4.7.1 示例 64
4.7.2 该对它做点儿什么 64
4.7.3 小结 65
4.8 冗长安装 65
4.8.1 示例 66
4.8.2 该对它做点儿什么 67
4.8.3 小结 68
4.9 过分保护 68
4.9.1 示例 69
4.9.2 该对它做点儿什么 69
4.9.3 小结 70
4.10 总结 70
第5章 可维护性 71
5.1 重复 72
5.1.1 示例 72
5.1.2 该对它做点儿什么 73
5.1.3 小结 75
5.2 条件逻辑 75
5.2.1 示例 76
5.2.2 该对它做点儿什么 76
5.2.3 小结 77
5.3 脆弱的测试 78
5.3.1 示例 78
5.3.2 该对它做点儿什么 79
5.3.3 小结 80
5.4 残缺的文件路径 80
5.4.1 示例 81
5.4.2 该对它做点儿什么 81
5.4.3 小结 83
5.5 永久的临时文件 83
5.5.1 示例 84
5.5.2 该对它做点儿什么 85
5.5.3 小结 86
5.6 沉睡的蜗牛 86
5.6.1 示例 87
5.6.2 该对它做点儿什么 88
5.6.3 小结 89
5.7 像素完美 89
5.7.1 示例 89
5.7.2 该对它做点儿什么 90
5.7.3 小结 93
5.8 参数化混乱 94
5.8.1 示例 95
5.8.2 该对它做点儿什么 98
5.8.3 小结 99
5.9 方法间缺乏内聚 100
5.9.1 示例 100
5.9.2 该对它做点儿什么 101
5.9.3 小结 104
5.10 总结 104
第6章 可信赖 106
6.1 注释掉的测试 107
6.1.1 示例 107
6.1.2 该对它做点儿什么 108
6.1.3 小结 108
6.2 歧义注释 109
6.2.1 示例 109
6.2.2 该对它做点儿什么 110
6.2.3 小结 111
6.3 永不失败的测试 111
6.3.1 示例 112
6.3.2 该对它做点儿什么 112
6.3.3 小结 113
6.4 轻率承诺 113
6.4.1 示例 114
6.4.2 该对它做点儿什么 115
6.4.3 小结 116
6.5 降低期望 117
6.5.1 示例 117
6.5.2 该对它做点儿什么 118
6.5.3 小结 118
6.6 平台偏见 119
6.6.1 示例 119
6.6.2 该对它做点儿什么 120
6.6.3 小结 121
6.7 有条件的测试 122
6.7.1 示例 122
6.7.2 该对它做点儿什么 123
6.7.3 小结 124
6.8 总结 124
第三部分 消遣
第7章 可测的设计 126
7.1 什么是可测的设计 126
7.1.1 模块化设计 127
7.1.2 SOLID设计原则 128
7.1.3 上下文中的模块化设计 129
7.1.4 以测试驱动出模块化设计 130
7.2 可测性的问题 130
7.2.1 无法实例化某个类 130
7.2.2 无法调用某个方法 131
7.2.3 无法观察到输出 131
7.2.4 无法替换某个协作者 131
7.2.5 无法覆盖某个方法 132
7.3 可测的设计的指南 132
7.3.1 避免复杂的私有方法 133
7.3.2 避免final方法 133
7.3.3 避免static方法 134
7.3.4 使用new时要当心 134
7.3.5 避免在构造函数中包含逻辑 135
7.3.6 避免单例 137
7.3.7 组合优于继承 138
7.3.8 封装外部库 138
7.3.9 避免服务查找 139
7.4 小结 140
第8章 用其他JVM语言来编写测试 142
8.1 混合使用JVM语言的前提 142
8.1.1 通用收益 143
8.1.2 编写测试 144
8.2 用Groovy来编写测试 146
8.2.1 简化的测试setup 146
8.2.2 Groovy式的JUnit 4测试 148
8.3 BDD工具的表达力 149
8.3.1 用easyb写Groovy需求说明 149
8.3.2 Spock Framework:编写更具表达力测试的激素 150
8.3.3 Spock Framework的测试替身也打了激素 152
8.4 小结 153
第9章 加速执行测试 155
9.1 追求速度 156
9.1.1 对速度的需要 156
9.1.2 进入状况 156
9.1.3 对构建进行性能分析 157
9.1.4 对测试进行性能分析 160
9.2 令测试代码加速 162
9.2.1 别睡觉,除非你累了 163
9.2.2 当心膨胀的基类 163
9.2.3 当心冗余的setup与teardown 165
9.2.4 挑剔地添加新测试 166
9.2.5 保持本地运行,保持快速 167
9.2.6 抵御访问数据库的诱惑 168
9.2.7 没有比文件I/O更慢的I/O了 169
9.3 令构建加速 171
9.3.1 RAM磁盘带来更快的I/O 172
9.3.2 并行构建 173
9.3.3 改换为高性能CPU 177
9.3.4 分布式构建 179
9.4 小结 183
附录A JUnit入门 185
附录B 扩展JUnit 192

本目录推荐