TestableMock这一篇就够了
TestableMock简介
TestableMock是基于源码和字节码增强的Java单元测试辅助工具，包含以下功能：
- 快速Mock任意调用：使被测类的任意方法调用快速替换为Mock方法，实现"指哪换哪"，解决传统Mock工具使用繁琐的问题
- 访问被测类私有成员：使单元测试能直接调用和访问被测类的私有成员，解决私有成员初始化和私有方法测试的问题
- 辅助测试void方法：利用Mock校验器对方法的内部逻辑进行检查，解决无返回值方法难以实施单元测试的问题
- 快速构造参数对象：生成任意多层嵌套的对象实例，并简化其内部成员赋值方式，解决被测方法参数初始化代码冗长的问题
快速上手
Maven项目中使用
在项目pom.xml文件中，增加testable-all依赖和maven-surefire-plugin配置，具体方法如下。
在dependencies列表添加TestableMock依赖：
<dependencies>
<dependency>
<groupId>com.alibaba.testable</groupId>
<artifactId>testable-all</artifactId>
<version>０.５.１</version>
<scope>test</scope>
</dependency>
</dependencies>最后在build区域的plugins列表里添加maven-surefire-plugin插件（如果已包含此插件则只需添加<argLine>部分配置）：
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-javaagent:${settings.localRepository}/com/alibaba/testable/testable-agent/${testable.version}/testable-agent-${testable.version}.jar</argLine>
</configuration>
</plugin>
</plugins>
</build>若项目同时还使用了Jacoco的on-the-fly模式（默认模式）统计单元测试覆盖率，则需在<argLine>配置中添加一个@{argLine}参数，添加后的配置如下：
<argLine>@{argLine} -javaagent:${settings.localRepository}/com/alibaba/testable/testable-agent/${testable.version}/testable-agent-${testable.version}.jar</argLine>在Gradle项目中使用
在build.gradle文件中添加TestableMock依赖：
dependencies {
testImplementation('com.alibaba.testable:testable-all:0.5.1')
testAnnotationProcessor('com.alibaba.testable:testable-processor:0.5.1')
}然后在测试配置中添加javaagent：
test {
jvmArgs "-javaagent:${classpath.find { it.name.contains("testable-agent") }.absolutePath}"
}若是基于Robolectric框架的Android项目，则添加TestableMock依赖方法同上，添加javaagent配置方法如下：
android {
testOptions {
unitTests {
all {
jvmArgs "-javaagent:${classpath.find { it.name.contains("testable-agent") }.absolutePath}"
}
}
}
}编码规范
1. 非标准位置的Mock容器类
TestableMock会依次在以下两个位置寻找Mock容器：
- 默认位置测试类中名为Mock的静态内部类（譬如原类型是Demo，Mock容器类为DemoTest.Mock）
- 同包路径下名为被测类+Mock的独立类（譬如原类型是Demo，Mock容器类为DemoMock）
倘若实际要使用的Mock容器类不在这两个位置，就需要在测试类上使用@MockWith注释了。一般来说，造成Mock容器类不在默认位置的原因可能有两种：复用Mock容器、集中管理Mock容器
另一种情况是开发者希望将Mock方法的定义与测试类本身分开，以便进行集中管理（或规避某些扫描工具的路径规则），譬如形成下面这种目录结构：
src/
main/
com/
demo/
service/
DemoService.java
test/
com/
demo/
service/
DemoServiceTest.java
mock/
service/
DemoServiceMock.java此时需要在测试类上显式的指定相应的Mock容器类，不过这种情况在实际中并不太常见。
2. 非标准位置的测试类
从TestableMock的原理来说，测试类的位置其实只是作为“被测类”与“Mock容器类”之间建立关联的参照物。当测试类的位置不是默认约定的被测类+Test时，上述首选的Mock容器位置就不成立了。但此时次选Mock位置依然可用，即如果Mock容器类的位置是被测类+Mock，那么Mock置换就依然能够正常进行。
但此时测试类与Mock容器之间的关联丢失了，因此需要为测试类使用@MockWith注解来显式的建立关联。例如：
public class DemoService { // 被测类
...
}
public class DemoServiceMock { // Mock容器类
...
}
@MockWith(DemoServiceMock.class) // 测试类由于丢失与Mock容器的关联，需要@MockWith注解
public class ServiceTest {
...
}3. 在一个测试类中测试多个被测类
这是非标准位置测试类的一种特殊情况，当一个测试类里同时测试了多个业务类（被测类），其名称要么只能与其中某个被测类有+Test的命名符合，要么不与其中任何一个被测类有命名相关性。
假设所有被测类的Mock容器均采用被测类+Mock约定命名（否则参考前一条规则，被测类也需要显式加@MockWith）。若该测试类本身命名不符合其中任何一个被测类+Test约定的情况，需要为该测试类加一个无参数的@MockWith注解（即使用默认值，相当于@MockWith(NullType.class)），用于标识此类需参与TestableMock的预处理。
4. 使用不包含Mock方法的Mock容器类
为了加快搜索Mock容器类的速度，在扫描过程中，TestableMock只会将自身定义有Mock方法（包含@MockMethod或@MockMockConstructor注解的方法）以及明确被@MockWith指向的类识别为有效的Mock容器，而不会去遍历其父类。
假如出于某些极特殊原因要使用无Mock方法的类型作为Mock容器，譬如希望将实际Mock方法均定义在父类，实际使用的子容器仅仅重载父类的某些特定方法。此时即使Mock容器类的位置符合约定，为了能够被识别，依然应该在相应的测试类上增加对Mock容器类的@MockWith引用。
注意事项：
- 编写测试类时注意类的路径要和被测试类保持一致；
- 当测试类与被测试类不是按照＂测试类＋Ｔｅｓｔ＂的规则命名时需要使用＠ＭｏｃｋＷｉｔｈ注解进行关联；
- 初始化被测类中通过@Autowired或@Resource注入的私有字段时若该对象的方法在测试时需要被Ｍｏｃｋ，则无需初始化，其他情况可以手动ｎｅｗ或依赖ｓｐｒｉｎｇ注入
设计与原理
与常见的Mock工具在每个测试用例里写Mock定义不同，TestableMock让每个业务类直接提供自己的Mock方法集合，描述自身在测试时需要被Mock的调用以及相应替代逻辑（即每个业务类有自己的独立Test类和独立Mock类）。采用约定优于配置，降低Mock学习理解成本、减少冗余信息。
这种设计基于两项基本假设：
- 同一个测试类里，一个测试用例里需要Mock掉的方法，在其他测试用例里通常也都需要Mock。因为这些被Mock的方法往往访问了不便于测试的外部依赖。
- 需要Mock的调用都来自被测类的代码。（此假设是符合单元测试初衷的，即单元测试只应该关注当前单元的内部行为，单元外的逻辑应该被替换为Mock）
据此通过约定来简化符合该假设的单元测试场景，通过配置来支持其余复杂的使用场景。
TestableMock的原理可以用一句话概括：利用JavaAgent动态修改字节码，把被测的业务类中与所有与Mock方法定义匹配的调用在单元测试运行时替换成对Mock方法的调用。
最终达到的效果则是，不论代码用什么服务框架、什么对象容器，不论要Mock的目标对象是注入的、new出来的、全局的还是局部的，不论要Mock的目标方法是私有的、外部的、静态的、继承来的或者重载过的，全部无差别通吃，让单元测试回归简单。
主流框架对比
除TestableMock外，目前主要的Mock工具主要有Mockito、Spock、PowerMock和JMockit，基本差异如下：
| 工具 | 原理 | 最小Mock单元 | 对被Mock方法的限制 | 上手难度 | IDE支持 |
|---|---|---|---|---|---|
| Mockito | 动态代理 | 类 | 不能Mock私有/静态和构造方法 | 较容易 | 很好 |
| Spock | 动态代理 | 类 | 不能Mock私有/静态和构造方法 | 较复杂 | 一般 |
| PowerMock | 自定义类加载器 | 类 | 任何方法皆可 | 较复杂 | 较好 |
| JMockit | 运行时字节码修改 | 类 | 不能Mock构造方法(new操作符) | 较复杂 | 一般 |
| TestableMock | 运行时字节码修改 | 方法 | 任何方法皆可 | 很容易 | 一般 |
Mockito是Java最老牌的Mock工具，稳定性和易用性较好，IntelliJ和Eclipse都有专用插件支持。相对不足之处在于Mock功能稍弱，在必要情况下需与其他Mock工具配合使用。
Spock是一款代码可读性非常高的单元测试框架，内置Mock支持，具有很好的整体感。由于同样基于动态代理实现，其不足点与Mockito类似。
PowerMock是一款功能十分强大的Mock工具，其基本语法与Mockito兼容，同时扩展了许多Mockito缺失的功能，包括对支持对私有、静态和构造方法实施Mock。但由于使用了自定义类加载器，会导致Jacoco在默认的on-the-fly模式下覆盖率跌零。
JMockit是一款功能性与易用性均居于Mockito与PowerMock之间的Mock工具，较好的弥补了两者各自的不足。该项目在2017年尝试推出JMockit2重写版本但未能完成，目前处于不活跃的维护状态。
相比之下，TestabledMock的功能与PowerMock基本平齐，且极易上手，只需掌握@MockMethod注解就可以完成绝大多数任务。
当前TestableMock的主要不足在于，编写Mock方法时IDE尚无法即时提示方法参数是否正确匹配。若发现匹配效果不符合预期，需要通过自助问题排查文档提供的方法在运行期进行校验。这个功能未来需要通过扩展主流IDE插件来提供。
此外，由于TestableMock独辟蹊径的采用基于单个方法的Mock机制，将Mock方法定义与单元测试用例解耦，一方面使得Mock方法具有默认可复用性，单元测试用例也因此变得更干净纯粹，另一方面也导致Mock方法定义变得零散，生命周期管理起来相对困难，对现有开发者的Mock编写习惯会带来一定改变。