最简单舒适的Mock测试应该是怎样的？
指着源文件调用了外部依赖的那行代码说：
“你，在测试的时候，换成这个假的调用！”
结束。
甭管他是私有方法、静态方法，还是别的类的方法，直接换掉，不要有任何多余动作。
Mock测试八股文
Java的Mock工具伴随着单元测试技术不断迭代发展，可谓前仆后继、历久弥新，虽然原理各不相同，但核心的使用模式却几乎没发生过多少变化。不论是当下流行的Mockito和PowerMock，或是曾经著名的JMockit、EasyMock、MockRunner等等，基本使用套路都是：先初始化、然后定义Mock对象，最后通过某种机制把定义好的Mock对象送回被测类，替换原本的被调用对象。
来个Mockito测试的实际代码感受一下。
// 第一步：初始化 Mockito
@RunWith(MockitoJUnitRunner.class)
public class RecordServiceTest
{
// 第二步：定义Mock对象
@Mock
DatabaseDAO databaseMock;
// 第三步：定义测试用例
@Test
public void saveTest()
{
// 第四步：定义替代方法
when(databaseMock.write()).thenReturn(4);
// 第五步：注入Mock对象
RecordService recordService =
new RecordService(databaseMock);
// 第六步：执行测试内容
boolean saved = recordService.save("demo");
// 第七步：验证测试结果
assertEquals(true, saved);
// 第八步：验证Mock方法被执行
verify(databaseMock, times(1)).write();
}
}
根据不同的实现原理，将Mock对象送回被测方法的手段有许多种。
基于动态代理实现的Mockito比较符合直觉，但除了能用@InjectMocks支持 @Autowired注入的Spring Bean以外，几乎没提供太多黑魔法，因此要求用户代码要写得“可测试”。若要换的对象没用依赖注入机制，Mockito就帮不上忙了。
基于自定义类加载器的PowerMock能用@PrepareForTest绕进被测类里去替换Mock对象，但副作用是会让Jacoco默认的on-the-fly模式测试覆盖率会全部跌零。PowerMock的使用流程和Mockito十分 相似，只是功能更多了，开发者的学习曲线也变得更加陡峭。
基于动态字节码修改实现的JMockit要技高一筹，它在不影响测试覆盖率的情况下，仅通过“局部手术”就能让被测方法里的Mock目标“狸猫换太子”。不过，JMockit不仅要求每个用例的开头和结尾采用固定结构，而且发明了一种并不太符合 Java 习惯的Mock定义语法，妥妥的将自己做成了一款“测试框架”。 同样看个例子。
// 第一步：初始化JMockit
@RunWith(JMockit.class)
public class PerformerTest {
// 第二步：定义Mock对象
@Mocked
private Collaborator collaborator;
// 第三步：定义被测对象
// 隐含注入Mock对象逻辑
@Tested
private Performer performer;
// 第四步：定义测试用例
@Test
public void testThePerformMethod() {
// 第五步：定义替代方法
new Expectations() {{
collaborator.work("bar"); result = 10;
}};
// 第六步：执行测试内容
boolean res = performer.perform("test");
// 第七步：验证测试结果
assertEquals(true, res);
// 第八步：验证Mock方法被执行
new Verifications() {{
collaborator.receive(true);
}};
}
}
其余几款Mock工具使用流程基本雷同，不再列举。这个神奇的规律表明，在任何完整的Mock测试过程里，我们都在习以为常的遵循一种固定的八段式结构。而且这八个步骤里，有五个都与Mock相关。
本来只是让Mock工具客串一下外部依赖，怎么它就喧宾夺主的掌控起整个测试结构了呢？
极简的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，用它！用它！用它！????????????
猜你喜欢: