简介
阿里巴巴研发效能团队开源的Java单元测试增强工具，换种思路写Mock，让单元测试更简单。
无需初始化，不挑测试框架，甭管要换的方法是被测类的私有方法、静态方法还是其他任何类的成员方法，也甭管要换的对象是怎么创建的。写好Mock方法，加个@MockMethod注解，一切统统搞定。
极简的TestableMock
为了探索更轻量易用的Mock测试手段，我们尝试给工具减负，让Mock的定义和置换干净利落，最终设计了一款极简风格的测试辅助工具TestableMock（开源地址见文末）。
在TestableMock的世界里，Mock就是指定目标方法，定义替代实现，然后看着它在测试运行的时候被自动换掉，从头至尾只需一个注解：@MockMethod。若将前面的第一个例子改成用TestableMock来实现，大概长这个样子。
public class RecordServiceTest
{
// 定义Mock目标和替代方法
// 约定Mock方法比原方法多一个参数，传入调用者本身
// 因此是替换DatabaseDAO类的int write()方法调用
@MockMethod
int write(DatabaseDAO origin) { return 4; }
// 定义测试用例
@Test
public void saveTest()
{
// 执行测试内容
RecordService rs = new RecordService();
boolean saved = rs.save("demo");
// 验证测试结果
assertEquals(true, saved);
// 验证Mock方法被执行
TestableTool.verify("write").times(1);
}
}
一共五个步骤，与Mock相关的只有两处。无需初始化框架，且Mock定义无需侵入测试用例，更无需开发者操心Mock方法如何注入。一切被@MockMethod注解安排的明明白白：在被测类中凡是调用DatabaseDAO对象write()方法的地方，统统变成空调用并且返回数值“4”。
与以往Mock工具总是要替换整个对象的思路不同，TestableMock直接替换目标方法，脑回路无比简单，这种简化设计主要基于两条基本假设：
- 假设一：同一个测试类里，一个测试用例里需要Mock掉的方法，在其他测试用例里通常也都需要Mock。因为这些被Mock的方法往往访问了不便于测试的外部依赖。
- 假设二：需要Mock的调用都来自被测类的代码。此假设是符合单元测试初衷的，即单元测试只应该关注当前单元的内部行为，单元外的逻辑应该被替换为Mock。
对于假设一，TestableMock允许有少量特例。比如上述Mock方法里，如果仅对从save方法里的write()调用进行Mock，可以使用TestableTool工具类进行辅助判断。
@MockMethod
int write(DatabaseDAO origin) {
switch(TestableTool.SOURCE_METHOD) {
case "save": return 10;
default: return origin.write();
}
}
假设二通常不应该有特例，否则意味着是单元测试本身写法有问题。
除此以外，TestableMock的“轻量”还体现在它不挑合作伙伴，代码里没有为任何运行框架或测试框架定制逻辑。不论项目使用Spring、JFinal还是Quarkus，不论测试使用JUnit4、JUnit5还是TestNG，不论覆盖率统计使用Jacoco还是其他工具，都能轻松上岗。同时，除了Mock被测类中任意对象的方法调用，TestableMock还能Mock被测类自身的私有成员方法、静态方法、以及new操作符。值得一提的是，new操作符的Mock方法返回的既可以是一个真实对象，也可以是一个经过动态代理包装的Mock对象。但TestableMock并不负责生成此类Mock对象，因为在这方面，Mockito等传统Mock工具已经做得足够好了，可以直接拿来配合使用、取长补短。
同样是Mock工具，TestableMock却能将Mock所需的各种准备工作极大简化，那么它相比传统Mock工具是否有什么缺点呢？TestableMock并未引入重大的底层新技术，在软件设计领域有一条不成名的定律：任何非颠覆式的改进都是一种trade-off，有得必有失。在TestableMock极简的体验背后，舍弃的其实就是不符合上述两点假设的非典型使用场景。由于将Mock方法和测试用例分开定义，倘若Mock方法里有太多需要区分调用来源的if和switch，就会使得代码逻辑被打散、不便于阅读。所幸，作为一位资深踩坑员，我可以告诉大家，这类特例并不常见。反而更常见的情况是有许多测试用例需要使用相同的Mock方法，此时将Mock定义独立出来更加有助于减少重复代码，因此结果通常都是利大于弊的。
TestableMock的原理
简单来说，TestableMock利用了运行时字节码修改技术，在单元测试启动时扫描测试类和被测类的字节码，完成Mock方法替换。
这一看似理所当然的技术选型背后，浓缩了TestableMock对功能齐备和极致轻量的双重追求。
现实中的Java单元测试Mock工具原理主要有三类，其典型代表列举如下：
- 动态代理：Mockito、EasyMock、MockRunner
- 自定义类加载器：PowerMock
- 运行时字节码修改：JMockit、TestableMock
在三种机制里，动态代理只在被测类的外周做手脚，不改动被测类本身，因此最安全，但功能也最弱。这类Mock工具对被Mock的方法比较挑剔，final类型、静态方法、私有方法全都无法覆盖。
自定义类加载器和动态字节码修改都会修改被测类的字节码，前者完全接管测试类的加载过程，后者则是在类加载完成后再对字节码做“二次改造”。从功能而言，两者没有太大差异，都可以实现对几乎任何类型和方法的Mock。两者的主要差异在于机制的启用方式，为了让自定义类加载器生效，需要针对不同的测试框架进行有区分的特殊处理，譬如在JUnit中使用@RunWith注解。这一点体现在PowerMock上就表现为，与不同测试框架配合使用时，它的注解搭配是有明确区别的。
为了与测试框架完全解耦，TestableMock通过直接扫描测试类中是否存在@MockMethod（或者@MockConstructor）修饰的方法，来自动判断是否要进行相应的初始化准备工作，实现了只需一个注解就能完成Mock初始化、定义和置换的极致体验。加之以可复用的方法（而非整个类型）作为粒度执行Mock替换，整个过程对测试的代码编写毫无侵入。
除了以上的三种方法，是否还有别的Mock实现手段呢？其实TestableMock的早期版本还尝试过一种做法：利用JSR-269规范的插件化注解处理器（Pluggable Annotation Processing）在代码编译期对被编译的源码进行修改。这种机制也能实现将源码中的方法调用换成Mock调用的目的，但它带来了两个棘手的问题。一是修改过的源码会被打包进最终生成的jar，导致生产包内容被篡改，此问题其实可通过在打包前增加一个class文件还原的步骤解决，但比较低效且并不优雅。另一个问题则是由于修改的是源码，因此对每种JVM语言都要单独实现，通用性不佳。TestableMock在迭代中逐步舍弃了基于JSR-269的Mock方案，转而利用这种机制实现了另一项功能：被测类私有成员访问。
超越Mock工具
TestableMock来自阿里云·云效团队，秉持云效让研发工作更简单的理念，它所承载的职责是 “让Java没有难测的方法”，这也是TestableMock项目名字的由来。
除了独具一格的Mock功能，TestableMock还提供了两项单元测试增强能力。
一项是让单测用例可以直接访问被测类的私有成员。
“该不该测试私有方法”这个话题一直在Java单元测试的圈子里颇有争议。没错，仅集中于Java圈子，因为一些较新的编程语言，比如Python、Golang、Rust都从源头上避免了这个争论发生：Python的“私有方法”只是一种命名约定，Golang默认同包内所有方法皆可访问，而Rust的单元测试是和被测代码放在一起的。也就是说这些新式语言早都已经默认，单元测试可以访问私有方法，怎么舒服怎么来。Java代码由于要测试private方法就得将方法可见性改为default或者public，破坏了封装，这根导火索引燃了面向对象保守派与实用主义激进派的意识形态之争。可是程序员何必为难程序员，“通过公有方法间接测试私有方法”在实际操作的时候只会让编写测试者非常蛋疼。TestableMock为测试类准备了一个@EnablePrivateAccess注解来快速实现可访问性的增强，使所有在测试类中访问相应被测类的私有成员代码都会在编译期被自动改为合法的反射调用，而访问其他类的私有方法则依然不被允许，该限制的地方限制，该放宽的地方放宽。
另一项是辅助测试没有返回值的void类型方法。
“没返回值的方法怎么测试”这是个业界并无太大观点分歧，却也至今尚未出现简单实用解决方案的技术课题。值得指出的是，void类型方法虽然不会直接返回计算结果，但一定会在其内部引起某种全局状态改变或引发某种“函数副作用”，比如输出日志、调用外部系统等等。既不返回数据也不产生任何副作用的方法毫无价值。通过TestableMock的私有成员访问机制和Mock验证器功能，可以快速验证被测类的内部状态变化，或是验证测方法中产生副作用的调用语句是否被正确执行且传入了预期的参数值。至此，Java项目void类型方法难以测试的历史或许将被终结。
总结
功能比PowerMock毫不逊色，
用法比Mockito更加简洁，
不挑框架，指哪换哪，
一个@MockMethod注解打天下。
单元测试是保障代码可重构和抗腐化的一种有效手段，但在实践的过程中，许多开发者最终被单元测试的条条框框与编写成本击退。实用主义单测增强工具TestableMock在提供万能Mock注入能力的同时，将单元测试编写的各方面成本均拉到了历史新低点。
让Mock返璞归真，让测试告别繁琐，TestableMock，用它！用它！用它！
- 项目开源地址：https://github.com/alibaba/testable-mock
- Gitee国内镜像：https://gitee.com/mirrors_alibaba/testable-mock
注意：本文归作者所有，未经作者允许，不得转载
