写Java单元测试的朋友，多半经历过这种拧巴时刻：被测类里明明只是一个小方法，但它内部调了一个private工具方法、new了一个第三方对象，或者走了个static工厂。你想把它替换掉，常规Mockito不支持私有方法，PowerMock虽然支持，可JDK版本一升级就各种原生报错；改成反射一写就是十几行，还丑得不敢commit。我第一次在开源项目里看到TestableMock时，第一反应是：这不就是我一直想要的东西吗？阿里开源的这套Mock框架，能做到不修改被测类任何代码，在测试运行时直接替换它内部调用的私有方法、静态方法、构造方法甚至成员变量，而且基于字节码增强实现，不依赖反射那些脆弱的黑魔法。
这篇文章不打算把官方文档抄一遍，而是把我实际使用TestableMock这段时间的接入配置、核心注解用法、底层原理和踩坑记录整理成一套可以直接上手的经验。适合刚被单元测试私有方法折磨的Java后端开发，也适合正在做单测框架选型对比的技术负责人。
1. 单测Mock之痛与TestableMock的破局思路
1.1 传统Mock工具的四大痛点
在讲TestableMock之前，先捋一下传统Mock工具在Java单元测试里让人难受的几个地方。这里不是否定Mockito，而是想说明TestableMock到底解决了什么问题。
痛点一：私有方法mock成本极高。Mockito本身不提供私有方法的mock能力，网上最常见的方法是“把private改成包级可见（default）”，这等于为了测试改生产代码，污染代码结构；稍微讲究点的用反射拿Method再setAccessible(true)，可一旦方法签名变动，反射代码也跟着崩，维护成本很高；上PowerMock可以做到，但PowerMock和JDK高版本的兼容性一直是老大难，很多团队宁可绕路也不肯引入。
痛点二：静态方法和构造方法难以替换。被测类内部调了RandomUtil.randomString(6)这类静态方法，或者自己new PriceCalculator(0.2)，用Mockito的时候只能把静态方法封装成实例方法，或者用工厂模式、依赖注入重构代码。本质上是“为了让类能测而改结构”，顺序反了。
痛点三：PowerMock兼容性包袱太重。PowerMock的启动原理是自定义类加载器重新加载字节码，这在JDK 8时代还算稳，到了JDK 11、JDK 17就经常因为模块系统报错，更别说和JaCoCo覆盖率插件配合时的顺序冲突。我已经不止一次看到团队因为PowerMock无法升级JDK而卡住技术栈升级。
痛点四：Mockito verify交互验证和Mockito mock对象的分工不清晰。很多新人写单测时不管什么都doReturn().when()，导致测试用例断言的全是“mock对象之间互相调用”，与被测类的真实行为脱节。
把四个痛点放一起看，会发现它们指向同一个诉求：能不能不修改被测代码、不引入脆弱的重加载机制，就能把类内部的方法调用替换掉？这正是TestableMock的切入点。
1.2 TestableMock的设计哲学：零代码侵入、按测试类隔离
TestableMock的核心设计哲学可以用一句话概括：默认不改变被测类的任何源码，通过字节码增强在测试运行时把方法调用重定向到mock方法。它把“mock什么”和“在哪里生效”拆成了两个维度：
@MockWith标注在测试类上，声明本测试类要生效的mock集合。@MockMethod标注在mock方法上，声明要替换哪个类的哪个方法。
与Mockito“创建一个代理对象替换依赖”的思路不同，TestableMock替换的是“被测类内部的方法调用指令”。换句话说，Mockito是站在对象外面包装一层替身，TestableMock是站在对象内部改变某个方法执行的路径。
这个设计带来的直接好处是：被测类里那些完全不依赖外部容器的私有方法、静态工具方法、构造调用，都能在不改变类结构的情况下被替换；而且mock的作用域是绑定在测试类上的，不会像PowerMock那样一个mock可能全局生效影响别的测试。
这三类工具放在一起看更直观：
| 能力项 | Mockito | PowerMock | TestableMock |
|---|---|---|---|
| 私有方法mock | 不支持 | 支持 | 支持 |
| 静态方法mock | 需额外扩展 | 支持 | 支持 |
| 构造方法mock | 不支持 | 支持 | 支持 |
| JDK高版本兼容性 | 较好 | 较差 | 较好 |
| 是否需要改被测代码 | 一般不需要 | 不需要 | 完全不需要 |
| mock作用域范围 | 按对象 | 全局影响风险高 | 按测试类隔离 |
注意上面最后一行：作用域隔离是TestableMock做得比较精细的地方，后面讲原理时我会再展开。如果你只是想把一个第三方静态方法替换掉，而不是为了兼容一堆老测试代码，TestableMock的学习曲线其实比PowerMock友好很多。
2. 依赖引入与Runner配置：两种接入方式的选择
2.1 Maven坐标与版本选择
TestableMock的Maven坐标是com.alibaba.testable:testable-all，我当前使用的是0.7.9，在JDK 8和JDK 11下都跑得比较稳。引入方式很简单，依赖范围设为test即可：
<dependency> <groupId>com.alibaba.testable</groupId> <artifactId>testable-all</artifactId> <version>0.7.9</version> <scope>test</scope> </dependency>如果你只用JUnit5，并且项目构建工具是Maven，加完这个依赖其实已经可以跑最基本的@MockWith用例了。但要注意，如果项目里同时存在JUnit4和JUnit5的混合依赖，或者你的测试类正在使用SpringRunner这类自定义Runner，就需要考虑下面说的插件接入方式。
2.2 插件接入与Runner接入的区别
TestableMock要生效，本质上需要让字节码增强器在测试JVM启动时被加载。官方提供了两条路：
第一条路，prepare插件方式，推荐。在pom.xml的build节点加入testable-maven-plugin：
<plugin> <groupId>com.alibaba.testable</groupId> <artifactId>testable-maven-plugin</artifactId> <version>0.7.9</version> <executions> <execution> <goals> <goal>prepare</goal> </goals> </execution> </executions> </plugin>这个prepare goal会在surefire的argLine参数里自动加上javaagent配置。这样做的最大好处是：测试类不需要改@RunWith，因此和SpringRunner、Mockito、JaCoCo等已有设施天然兼容，适合在老项目里直接落地。
第二条路，Runner方式。在JUnit4中，如果不想引入插件，可以在测试类上改用TestableMock提供的Runner；JUnit5则不需要额外写扩展类，TestableMock通过SPI自动注册。Runner方式的好处是不污染构建配置，但坏处是如果你已经在用SpringRunner，Runner只能有一个，会冲突。所以我的建议很明确：只要项目里已经有自定义Runner，就直接用插件方式，别折腾Runner切换。
2.3 和SpringRunner共存时的配置顺序
对于Spring Boot项目，常见组合是@RunWith(SpringRunner.class) @SpringBootTest。加了testable-maven-plugin之后，两个Runner不会同时出现，因为SpringBootTest还是用它自己的SpringRunner，TestableMock的agent在JVM启动时就已经挂载了，根本不需要抢Runner的位置，这算是这个方案的一个隐含好处。
但这里有一个很容易踩的配置坑：如果你在pom里手动配置了surefire的argLine，很可能会覆盖掉testable插件自动写入的agent参数。典型情况是项目里既有<argLine>配置又加了这个插件，结果测试一跑，TestableMock完全没有生效，日志里也看不到任何agent初始化信息。解决方式是把两者合并，例如：
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <argLine>${argLine} ${testable.argLine}</argLine> </configuration> </plugin>不同版本对agent参数名的写法略有差异，但核心思路一致：把TestableMock插件生成的argLine和你原有的argLine拼接起来，避免互相覆盖。排查测试不生效时，先看mvn命令里最终传给JVM的argLine是什么，这一步往往能解决一半的问题。
3. 核心用法：@MockWith与@MockMethod的编码范式
3.1 五分钟写一个可运行的Demo
直接上一个贴近实际业务的例子。假设有一个DemoService，它的generateOrderNo方法内部调用了私有方法、静态工具方法和成员变量方法：
package com.example.demo; import com.example.support.RandomUtil; import com.example.support.PriceCalculator; public class DemoService { private PriceCalculator calculator = new PriceCalculator(0.2); public String generateOrderNo(String prefix) { String timestamp = getTimestamp(); String random = RandomUtil.randomString(6); double price = calculator.calculate(100.0); return prefix + timestamp + random + "@" + price; } private String getTimestamp() { return String.valueOf(System.currentTimeMillis()); } }正常情况下，这个方法返回的结果包含当前毫秒数和随机字符串，测试没法做稳定断言。用TestableMock写成这样：
package com.example.demo; import com.alibaba.testable.core.annotation.MockMethod; import com.alibaba.testable.core.annotation.MockWith; import com.alibaba.testable.core.annotation.Testable; import com.example.support.PriceCalculator; import com.example.support.RandomUtil; import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; @MockWith(mocks = DemoServiceTest.DemoServiceMock.class, treatPrivateAsPublic = true) public class DemoServiceTest { @Testable private DemoService demoService; @Test public void testGenerateOrderNo() { String result = demoService.generateOrderNo("NO"); assertEquals("NO202501010000ABC123@88.8", result); } public static class DemoServiceMock { @MockMethod(targetClass = DemoService.class, targetMethod = "getTimestamp") private String mockGetTimestamp(DemoService self) { return "202501010000"; } @MockMethod(targetClass = RandomUtil.class, targetMethod = "randomString") private String mockRandomString(Class<?> self, int length) { return "ABC123"; } @MockMethod(targetClass = PriceCalculator.class, targetMethod = "calculate") private double mockCalculate(PriceCalculator self, double amount) { return 88.8; } } }测试类里通过@Testable自动创建了DemoService实例，treatPrivateAsPublic = true允许测试类直接访问被测类私有成员，同时generateOrderNo内部三个方法调用全部被mock掉，断言字符串就完全可控了。整个过程没有改动DemoService一行代码，也没有用反射。
3.2 self参数的规则与边界
上面例子中，mockGetTimestamp(DemoService self)和mockCalculate(PriceCalculator self, double amount)里的第一个参数是TestableMock的特殊约定，叫self参数。它表示“被mock方法所属的调用者实例”。
规则是这样的：
- mock实例方法时，如果你需要在mock方法里访问调用者对象，第一个参数就写该实例的类类型，TestableMock会自动把当前调用对象传进来；如果不需要访问，可以不写这个参数。
- mock静态方法时，对应的第一个参数类型是
Class<?>，表示目标类，例如mockRandomString(Class<?> self, int length)。 - self参数之后才是原方法的参数列表，顺序必须保持一致。
- 返回值类型必须与原方法一致。
很多初学者会困惑“为什么有的写法带self，有的不带”。判断标准就一条：这个mock方法内部是否需要读取调用者状态。比如要mock掉order.getPrice()并根据order的某些字段算返回值，这时候就需要self；如果只是固定返回一个常量，不带也完全没问题。
3.3 静态方法、构造方法和重载方法的写法
静态方法的mock，上面已经演示过了，核心是targetClass写静态方法所属类，第一个参数用Class<?>占位。再看一个更偏门的场景：如果被测类内部new Date()，你想让每次构造都返回固定时间，可以这样mock无参构造方法：
@MockMethod(targetClass = Date.class, targetMethod = "<init>") private Date mockDateInit(Class<?> self) { return new Date(0); }这里有个必须提醒的递归风险：如果你mock的是Date(long)有参构造，然后在mock方法里又new Date(0)，就会再次触发mock，形成无限递归。上面示例中mock的是无参构造，return new Date(0)调用的是有参构造，有参构造没有被mock，所以不会递归。如果确实需要mock有参构造，建议在mock方法里返回一个提前创建好的实例引用（比如通过测试类静态字段传入），而不是在mock方法体内再new。
重载方法是另一个签名陷阱高发区。当目标类存在多个同名方法，TestableMock无法只靠targetMethod区分，需要加targetDesc指定JVM方法描述符：
@MockMethod(targetClass = DemoService.class, targetMethod = "findOrder", targetDesc = "(Ljava/lang/String;J)Lcom/example/domain/Order;") private Order mockFindOrder(DemoService self, String orderId, long userId) { return new Order(); }写完整描述符确实繁琐，它的格式是(参数类型描述符)返回值描述符，基本类型用I、J、D、Z，对象类型用L全限定类名;。如果不确定描述符，可以用javap -s -p查看目标方法的签名。实际上，TestableMock文档里说targetDesc也可以省略，前提是目标方法在当前类中不重载；一旦重载了就必须写，这是定位bug时最容易忽略的一个点。
4. 更进一步：@Testable注入与私有成员访问
4.1 @Testable如何自动创建被测类实例
测试类里最常见的操作就是private DemoService demoService = new DemoService();。这么写没问题，但如果被测类构造方法里有依赖参数、或者需要注入一堆成员变量，每写一个测试类都要手写构造逻辑，很啰嗦。
@Testable注解就是为这个场景准备的。标注在测试类的字段上，TestableMock会在测试执行前自动为这个字段创建实例并注入：
@MockWith(mocks = DemoServiceTest.DemoServiceMock.class, treatPrivateAsPublic = true) public class DemoServiceTest { @Testable private DemoService demoService; }注意，@Testable创建的是普通POJO实例，不经过Spring容器，也不做任何依赖注入。如果你测的类本身依赖Spring管理的Bean，还是要老老实实用@SpringBootTest+@Autowired。@Testable的价值更多是省去手写new和便于结合下面的treatPrivateAsPublic访问私有成员。
4.2 treatPrivateAsPublic开启后的新姿势
@MockWith注解里有一个容易被忽略的属性treatPrivateAsPublic，默认是false。把它设为true之后，测试类里可以直接访问被测类的私有字段和私有方法，不再需要反射。
举个例子，被测类有个私有字段private Map<String, String> configMap，测试里想直接查看它被填充后的内容，以前要写：
Field field = DemoService.class.getDeclaredField("configMap"); field.setAccessible(true); Map<String, String> map = (Map<String, String>) field.get(demoService);开启treatPrivateAsPublic = true后，直接写demoService.configMap就可以了，IDE通常也会给出智能提示。这个特性在断言内部状态时非常香，但它也让测试类与被测类内部实现产生强耦合，用得过多会降低测试对重构的容忍度，我的建议是仅对确定需要断言的私有状态使用。
4.3 内部成员变量的处理思路
回到成员变量mock这个问题。上一节的DemoService里有private PriceCalculator calculator = new PriceCalculator(0.2);，generateOrderNo里调用了calculator.calculate(100.0)。我在测试类中mock的是PriceCalculator.calculate方法，而没有直接替换calculator字段本身。
这是一个很重要的思路：优先mock方法，而不是替换字段。因为mock方法的可读性好、和被测类内部实现耦合度低；而替换字段需要额外记住被测类内部字段名，一旦字段改名测试就崩。TestableMock本身也支持通过targetMethod指向字段名的写法来接管字段读取，但实际项目中我用到的频率很低。优先方法级mock，遇到确实需要替换整个字段的场景，再考虑用@Testable配合treatPrivateAsPublic直接给私有字段赋值，语义会更清晰。
5. 字节码增强原理：为什么能“不改被测代码”就完成替换
5.1 一次方法调用被替换的完整链路
前面一直在说“字节码增强”，可能有人觉得这是个黑盒。其实整个链路并不复杂：
- 测试JVM启动时，TestableMock的agent（或Runner）通过Java Instrumentation注册一个
ClassFileTransformer。 - 当被测类
DemoService被类加载器加载时，这个transformer会被触发。 - transformer检查当前测试线程的上下文，确认当前执行的测试类是否标注了
@MockWith。 - 如果命中，框架扫描该测试类内部mock类里的
@MockMethod方法，构建一张“目标方法坐标 → mock方法”的映射表。 - 然后通过javassist改动
DemoService的方法体，把内部调用指令（比如invokevirtual调用getTimestamp）重写成调用mock方法的指令。 - 测试结束后，JVM进程退出，一切恢复原样。
整个过程发生在类加载期，不改源码、不生成新的Test类、不依赖反射运行时调用，所以在绝大多数情况下对测试性能影响很小。
5.2 作用域隔离与线程级映射
TestableMock另一个值得说的设计就是mock作用域隔离。一个项目里可能有几十个测试类，类A测DemoService时把getTimestamp替换成固定值，类B不测它但也会用到DemoService，如果类B执行时getTimestamp还是被替换，那类B就跑错了。
TestableMock处理这个问题的思路是用测试线程上下文保存当前激活的mock映射表。只有当前测试类标注了@MockWith且正在执行时，映射表才会生效；脱离这个上下文，目标类的方法调用又回到原始实现。所以同一个被测类可以在不同测试类里被mock成不同行为，互不干扰。这也是它比PowerMock更让人放心的一点，PowerMock的mock静态方法一旦没清理干净，容易污染同JVM下的其他测试类。
5.3 原理带来的边界与限制
理解原理之后，很多事情就能推导出边界了。
第一，如果目标类早在TestableMock的transformer注册之前就已经被加载，那么增强时机就错过了。比如同一个JVM里某个测试类在DemoService加载之前就跑了，并且DemoService在它那边也被加载，那么后面的测试类再想mock它内部方法就可能不生效。实际中这更多发生在Gradle的fork配置或IDE的测试复用时，解决方案是给测试JVM配置隔离。
第二，JDK高版本的模块系统对java.base等内置模块类的修改限制非常严格。TestableMock主要面向业务项目的自定义类，如果要mock的是JDK核心类方法，建议不要硬来，而是用包装类或中间层隔离。
第三，CGLIB代理和JDK动态代理包裹过的Spring Bean，因为调用链经过代理对象，直接mock代理对象内部方法不一定能达到预期。这种情况要结合Spring的代理层级来看，通常建议mock目标接口方法，而不是代理类内部私有方法。
理解这些边界不是为了劝退，而是让你遇到“为什么Mock不生效”时能快速有个判断方向，而不是瞎试。
6. 坑位实录：我遇到过的Mock不生效问题与排查思路
6.1 一个“写法完全正确却不生效”的案例复盘
上个月我在一个Maven多模块项目里补单测，模块A是被测服务模块，模块B是公共模块。我在模块A的测试目录里写了测试类，mock模块B的RandomUtil.randomString，注解、签名、targetClass全部对了一遍，断点打在mock方法上，结果运行测试时进去的依然是真实方法体，返回的随机字符串让断言失败。
当时第一反应是“TestableMock没生效”，但项目里其他测试类用得好好的。后来一步步排查才发现，模块B的RandomUtil已经被模块A的主代码静态引用了，而且更容易被忽略的是：在执行mvn test时，RandomUtil可能已经被某个不相关的测试类抢先加载。类一旦被加载，后续测试类里的agent增强就无法对同一类重复修改，mock自然不生效。
最终解决方案是在surefire配置里把测试类的运行顺序调整，或者为这个用例单独设置forkCount，保证目标类在测试类运行前没有被加载。这个案例说明，多模块环境下“mock不生效”未必是注解写错，很可能是类加载时机踩坑。
6.2 从日志到断点的五步定位法
后来我总结了一套自己的排查流程，遇到mock不生效就按这个顺序查，效率很高：
| 步骤 | 操作 | 预期表现 |
|---|---|---|
| 1 | 查看测试启动日志中是否有TestableMock的agent初始化信息 | 有初始化信息说明agent加载成功 |
| 2 | 在mock方法入口打上断点，运行测试 | 进入mock方法说明映射生效 |
| 3 | 临时去掉@MockWith注解再运行 | 回归真实方法，说明框架整体生效，问题在映射建立 |
| 4 | 核对targetClass、targetMethod、targetDesc和方法签名 | 与反编译后的目标方法严格一致 |
| 5 | 在surefire配置中增加fork隔离，看是否因类加载时机导致 | 加fork后生效，说明是类过早加载 |
第4步看起来简单，但最花时间。重载方法漏写targetDesc、参数类型用了接口实现类而不是接口本身、mock方法返回类型写宽泛了，这些都属于“看起来对其实不对”。用javap -s自带描述符检查目标方法，可以省掉很多无效猜测。
6.3 方法签名、类加载器和Runner冲突的隐藏陷阱
再补充几个隐藏在细节里的坑。
坑一：mock方法写在普通内部类。TestableMock要求mock类能被框架实例化并访问，推荐写成测试类里的public static class。如果误写成非静态内部类，框架无法直接创建mock类实例，现象就是mock完全不生效，而且报错信息可能只出现在agent日志里。
坑二：自定义类型的ClassLoader不一致。多模块或使用Spring Boot打包插件时，同一个自定义类可能被不同ClassLoader加载。mock方法里写的targetClass类型是引用A类加载器，而运行时目标类实际是B类加载器加载，签名对不上，映射失败。如果怀疑是这个原因，在mock方法里打一个测试性的System.out.println输出self.getClass().getClassLoader()，对比一下就能确认。
坑三：JUnit4和JUnit5依赖同时存在。项目里如果同时引入了junit4和junit5两个依赖，会出现测试类实际由JUnit4的Runner执行，但TestableMock按JUnit5方式注册扩展，导致agent没接手。这种情况要么统一JUnit版本，要么明确用插件方式挂agent，不要混合依赖。
这些坑单独看都不大，但每一条都足够让一个下午的调试验证白费。记录下来，以后遇到同类问题可以先对号入座。
7. 在Spring Boot业务项目里的落地经验
7.1 不用推倒重来：老测试类如何平滑迁移
已经跑了一年多的老项目里全是Mockito和PowerMock写法的测试类，突然要用TestableMock，是不是要大改一遍？我的经验是不用。TestableMock与Mockito可以共存，Mesh迁移的关键是挑优先级。
我建议的迁移顺序是：先找私有方法最多的核心Service测试类，把它们从PowerMock切到TestableMock；普通依赖桩mock继续保留Mockito。一个测试类里同时用Mockito的@Mock、@InjectMocks和TestableMock的@MockWith并不冲突，因为两者作用域不同——Mockito控制的是测试类里注入的依赖引用，TestableMock控制的是被测类内部的字节码调用路径。
具体对照关系如下：
| 原PowerMock写法 | 迁移后的TestableMock写法 |
|---|---|
PowerMockito.mockStatic(RandomUtil.class)+when(...) | @MockMethod(targetClass = RandomUtil.class, targetMethod = "randomString") |
Whitebox.invokeMethod(obj, "privateMethod", args) | 开启treatPrivateAsPublic后直接调用私有方法 |
PowerMockito.whenNew(PriceCalculator.class).thenReturn(mock) | @MockMethod(targetClass = PriceCalculator.class, targetMethod = "<init>") |
迁移的时候记得把testable-maven-plugin一起加到pom里，确保agent正确挂载，否则单测在IDE里可能正常，在CI的mvn test里又不生效。
7.2 和Mockito的分工：谁mock内部方法，谁做交互校验
再说一下两者的分工策略。TestableMock强在“替换方法体”，Mockito强在“验证对象交互”。业务团队最终沉淀下来的写法是：
- 被测类内部调用的私有方法、静态方法、构造方法，交给TestableMock替换，保证测试数据可控。
- 被测类依赖的外部Service接口、FeignClient、Mapper等，仍用Mockito的
@Mock做依赖桩，并且用Mockito.verify确认调用次数和参数。 - 断言优先走返回值，其次走内部状态字段（开启treatPrivateAsPublic），较少依赖Mockito的verify做大量交互校验。
顺手分享一个组合场景的代码示意：
@MockWith(mocks = OrderServiceTest.OrderServiceMock.class, treatPrivateAsPublic = true) @SpringBootTest public class OrderServiceTest { @Autowired private OrderService orderService; @Mock private OrderMapper orderMapper; @Test public void testCreateOrder() { when(orderMapper.insert(any(OrderDO.class))).thenReturn(1); Order result = orderService.createOrder("userId-001"); assertNotNull(result); verify(orderMapper, times(1)).insert(any(OrderDO.class)); } public static class OrderServiceMock { @MockMethod(targetClass = OrderService.class, targetMethod = "generateOrderNo") private String mockGenerateOrderNo(OrderService self) { return "NO-FIXED-001"; } } }这个例子里，orderService是Spring容器里的真实Bean，orderMapper是被Mockito替换的依赖，generateOrderNo是OrderService内部私有方法，被TestableMock替换为固定值。三者各干各的活，没有冲突。
最后聊点个人体会。用TestableMock这段时间，我最大的感受是它不是替你解决所有测试问题，而是把以前“改生产代码才能测”的那部分成本彻底省掉了，让单元测试真正回归到“验真逻辑”而不是“迁就框架”。如果你也是被PowerMock兼容性搞得焦头烂额，或者正在给Spring Boot老项目补单测，建议挑一个小模块先试试，按上面第七节的分工方式开始迁移。踩坑的时候记得从第六节的五步定位法开始查，大多数问题其实都出在方法签名和agent接入方式上。祝大家都能写出不拧巴的单元测试。
