本文地址：http://t.csdn.cn/vS0Za
文章目录
- 代码现代化：你的代码可测吗？
- 你的代码可测吗？
- 标题如何让代码变得可测？
- 接缝的位置
- 接缝的类型
- 新生和外覆
- 为代码添加测试
- 决策表模式
- 测试的类型和组织
- 遗留系统中的测试策略
代码现代化：你的代码可测吗？
一个软件的自动化测试，可以从内部表达这个软件的质量，我们通常管它叫做内建质量（Build Quality In）。
你的代码可测吗？
不可测代码的类型：
- 在方法中构造了不可测的对象。
- 在方法中调用了不可测的静态方法
在测试中，我们通常把被测的元素（可能是组件、类、方法等）叫做 SUT（System Under Test），把 SUT 所依赖的组件叫做 DOC（Depended-on Component）。导致 SUT 无法测试的原因，通常都是 DOC 在当前的测试上下文中不可用。
DOC 不可用的原因通常有三种：
- 不能访问。比如 DOC 访问了数据库或其他需要部署的中间件、服务等，而本地环境没有这些组件，也很难部署这些组件。
- 不是当前测试期望的返回值。
- 执行这些 DOC 的方法会引发不想要的副作用。
标题如何让代码变得可测？
可以让 DOC 的行为发生改变的位置，叫做接缝（seam）。
把在 SUT 中创建接缝从而使 SUT 变得可测的方式，叫做提取接缝模式。
接缝的位置
通过构造函数注入进来
接缝也可以位于方法参数中
使用了依赖注入工具（比如 Spring），也可以给字段加 @Autowired 注解，这样接缝的位置就成了字段
接缝的类型
接缝的类型是指，通过什么样的方式来改变 DOC 的行为。
通过继承 DOC 来改变默认行为的接缝类型叫做对象接缝。
通过将 DOC 提取为接口，并用其他实现类来改变默认行为的接缝类型，就叫做接口接缝。
新生和外覆
代码隔离的四大类方法：
- 新生方法 sprout method
- 新生方法是可测的，你可以对它添加测试，以验证过滤逻辑的正确性。原来的方法虽然仍然不可测，但我们也没有让它变得更糟。
- 新生类 sprout class
- 接口、观察者、直接加功能类
- 外覆方法 wrapper method
- 外覆类 wrapper class
- 代理、装饰、aop方式
为代码添加测试
测试替身（Test Double）
Mock 框架：Mockito
决策表模式
对于这种分支条件较多的代码，我们可以梳理需求文档（如果有的话）和代码，找出所有的路径，根据每个路径下各个字段的数据和最终的值，制定一张决策表。
这种决策表不但清晰地提供了所有测试用例，而且给出了相应的数据，你可以很轻松地基于它来构建整个方法的测试。
测试的类型和组织
Mike Cohn 在十几年前曾经提出过著名的“测试金字塔”理论，遗留系统很难应用测试金字塔。
- 最顶层的 UI 测试是指从页面点击到数据库访问的端到端测试，用自动化的方式去模拟用户或测试人员的行为。
- 中间这层的服务测试也是某种意义的端到端测试，但它避开了 UI 的复杂性，而是直接去测试 UI 会访问的 API。
- 最底层的单元测试就是对某个方法的测试，平时开发同学写的大多是这方面的测试。
一种观点认为不管任何依赖都应该使用测试替身来代替；一种观点则认为只要 DOC 不访问数据库、不访问文件系统、不访问进程外的服务或中间件，就可以不用测试替身。前者的学名叫 solitary unit test，我管它叫“社恐症单元测试”；后者学名叫做 sociable unit test，我管它叫“交际花单元测试”。
遗留系统中的测试策略
遗留代码有很多特点，导致它们并不适合完全应用测试金字塔来组织测试。
- 首先，遗留系统的很多业务逻辑位于数据库的存储过程或函数中，代码只是用来传递参数而已。
- 其次，遗留系统的很多业务还位于前端页面中，位于 JSP、PHP、ASP 的标签之中。
对于前端中的业务逻辑，你可以先重构这些逻辑，将它们迁移到后端中，然后再编写单元测试或服务测试。这时的测试策略有点像一个钻石的形状。
