《遗留系统现代化》读书笔记（模式篇-代码现代化（一））

本文地址：http://t.csdn.cn/vS0Za

代码现代化：你的代码可测吗？

一个软件的自动化测试，可以从内部表达这个软件的质量，我们通常管它叫做内建质量（Build Quality In）。

你的代码可测吗？

不可测代码的类型：

• 在方法中构造了不可测的对象。
• 在方法中调用了不可测的静态方法

在测试中，我们通常把被测的元素（可能是组件、类、方法等）叫做 SUT（System Under Test），把 SUT 所依赖的组件叫做 DOC（Depended-on Component）。导致 SUT 无法测试的原因，通常都是 DOC 在当前的测试上下文中不可用。
DOC 不可用的原因通常有三种：

1. 不能访问。比如 DOC 访问了数据库或其他需要部署的中间件、服务等，而本地环境没有这些组件，也很难部署这些组件。
2. 不是当前测试期望的返回值。
3. 执行这些 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 的标签之中。

对于前端中的业务逻辑，你可以先重构这些逻辑，将它们迁移到后端中，然后再编写单元测试或服务测试。这时的测试策略有点像一个钻石的形状。