失效链接处理 |
有效的单元测试(Effective unit testing a guide for Java developers) PDF 下载
转载自:https://download.csdn.net/download/hsiayoong/11239590
本站整理下载:
版权归出版社和原作者所有,链接已删除,请购买正版
用户下载说明:
电子版仅供预览,下载后24小时内务必删除,支持正版,喜欢的请购买正版书籍:
http://product.dangdang.com/1372801136.html
相关截图:
资料简介:
这是一本关于单元测试的系统实践指南,由资深敏捷技术实践专家撰写,不仅全面阐释了单元测试用于软件设计的工具、方法、原则和*实践,而且对各种测试常见问题进行了深入分析,包含大量实践案例,可操作性强,能为用户高效编写优秀测试提供有效指导,让组织持续创造成功的产品和服务。
本书分为三部分,共9章。第一部分(第1—3章)主要阐述测试的目的与原因,并分析作为常用工具的测试替身的作用。第1章先从整体阐释测试先行所带来的价值,以及各种对测试和测试质量的影响,,第2章定义如何才能写出优秀的测试。第3章讨沦现代程序员最基本的工具之一——测试替身。第二部分(第4—6章)的目标是帮助我们更好地识别并修复测试代码中的坏味道。第4章展示破坏测试可读性的坏味道。第5章继续对破坏可维护性的测试提供建议。第6章涉及有关脆弱或不可靠的测试坏味道。第三部分(第7—9章)涉~Java程序员在编写测试时随时可能碰到的话题。第7章介绍可测的设汁的定义与作用。第8章探讨JVM语言的共生,以及如何用另一门语言来测试Java代码。第9章专门讨论对构建进行加速的问题。此外还包括两个附录,附录A介绍使用JUnit编写测试的入门知识。附录B探讨通过JUnit的API来扩展其内置功能
资料目录:
译者序 序言 前言 致谢 第一部分 基础 第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 |