内容简介

程序员修炼三部曲丛书包含了四本书，介绍了每个注重实效的程序员和成功团队所必备的一些工具。

注重实效的程序员都会利用反馈来指导开发，并驱动个人的开发流程。编码的时候，最有用的反馈来自于“单元测试”。

为了测试一座桥梁，不会只在晴朗的天气，开一辆汽车从桥中间穿过，就认为已经完成了对桥梁的测试。然而许多程序员却正在使用这种测试方法——把这种一次顺利通过称为“测试”。事实上，注重实效的程序员应该能够做得比这更好。

从这本书中，您能够学到：

编写更好，更快，并且bug更少的代码。

找到bug的隐身之处，并且学会如何修正这些bug。

在不使用整个项目的前提下，就可以测试一小段代码。

学会如何JUnit来简化测试代码。

如何在开发小组中展开高效的测试。

本书将借助面向Java的免费程序库JUnit来对单元测试进行描述；这些技术同样也适用于其它语言和框架（本丛书还有一本针对Java版本的姐妹书籍《单元测试之道C#版——使用UNnit》）。

《程序员修炼三部曲》是一套由四本小册子组成的丛书，旨在帮助解决程序员在日常工作中遇到一些具体问题和需要，覆盖了对于现代软件开发非常重要的基础性知识。这套丛书不仅展现了注重实效的实际技巧、工具使用，也贯穿了作者们在其名作《程序员修炼之道：从小工到专家》中所坚持的开发哲学。而所有这些，都是帮助开发人员和开发团队进行正常开发，并带来高开发效率的利器。

《单元测试之道Java版——使用JUnit》是本丛书的第二本（本书还有C#版本《单元测试之道C#版——使用JUnit》），阐述使用自由公开的JUnit程序库以Java语言进行单元测试，其内容也广泛适用于其他语言和框架程序库。本书主要内容包括：如何更高效地撰写bug更少的代码：如何发现bug的藏身之处以及如何清除bug；如何测试代码片断而不用牵连整个项目；如何利用JUnit简化测试代码；如何在团队中高效地进行测试，等等。

本书主要适用于具有一定编程和设计经验，但是对单元测试并不是很有经验的Java程序员。

作品目录

关于程序员修炼三部曲
前言
第1章 序言
1.1 自信地编码
1.2 什么是单元测试
1.3 为什么要使用单元测试
1.4 我需要做什么呢
1.5 如何进行单元测试
1.6 不写测试的借口
1.7 本书概要
第2章 你的首个单元测试
2.1 计划你的测试
2.2 测试一个简单的方法
2.3 更多的测试
第3章 使用JUnit编写测试
3.1 构建单元测试
3.2 JUnit的各种断言
3.3 JUnit框架
3.4 JUnit测试的组成
3.5 自定义JUnit断言
3.6 JUnit和异常
3.7 关于命名的更多说明
3.8 JUnit测试骨架
第4章 测试哪些内容：Right-BICEP
4.1 结果是否正确
4.2 边界条件
4.3 检查反向关联
4.4 使用其他手段来实现交叉检查
4.5 强制产生错误条件
4.6 性能特性
第5章 CORRECT边界条件
5.1 一致性
5.2 有序性
5.3 区间性
5.4 引用/耦合性
5.5 存在性
5.6 基数性
5.7 时间性
5.8 自己动手尝试
第6章 使用Mock对象
6.1 简单的替换
6.2 Mock对象
6.3 测试Servlet
6.4 Easy Mock对象
第7章 好的测试所具的品质
7.1 自动化
7.2 彻底的
7.3 可重复
7.4 独立的
7.5 专业的
7.6 对测试进行测试
第8章 在项目中进行测试
8.1 把测试代码放到哪
8.2 测试的礼貌
8.3 测试的频率
8.4 测试与遗留代码
8.5 测试与评审
第9章 设计话题
9.1 面向测试的设计
9.2 为测试而重构
9.3 测试类的不变性
9.4 测试驱动的设计
9.5 测试无效的参数
附录A Gotchas
A.1 只要代码能工作就可以
A.2 “冒烟”测试
A.3 “请让我的机器来运行”
A.4 浮点数问题
A.5 测试耗费的时间太多了
A.6 测试总是失败
A.7 在某些机器上测试失败
A.8 我的main没有被运行
附录B 安装JUnit
B.1 命令行安装
B.2 管理用吗
附录C JUnit
C.1 辅助类
C.2 基本模板
附录D 资源
D.1 网络资源
D.2 参考书目
附录E 注重实效的单元测试：总结
附录F 习题答案
索引
· · · · · ·

作者简介

Andrew Hunt和David Thomas是Pragmatic Programmers的合伙人。他们不但为客户开发复杂的软件系统，而且为开发者和项目经理提供具有实务的各种资源。他们的第一本书《程序员修炼之道——从小工到专家》（The Pragmatic Programmer:From jouneyman to master）是面向技术和实践的畅销书籍，旨在让编码过程更加高效和有趣。

精彩摘录

Right-BICEP:Right-结果是否正确？B-是否所有的边界条件都是正确的？I-能查一下反向关联吗？C-能用其他手段交叉检查一下结果吗？E-你是否可以强制错误条件发生？P-是否满足性能要求？

——引自第37页

毕竟，要是我们对手上正在写的代码的行为是否和我们的期望一致都没把握，那么其他形式的测试也都只能是浪费时间而已。

——引自第4页