Fan Lin

近期连续收到较多类似问题的反馈🤣 计划在`1.0`版本之前会加上“调用指定类所有方法自动Mock”的新注解`@MockAllMethods`，相关设计已完成，待开发。

正常来说应该不需要`-noverify`参数，能帮忙提供一个会导致“stack size doesn't match”错误的脱敏代码示例么？

Mock只对业务类中的调用生效，因为Mock的目的本来就是在测试的时候，需要在不直接修改业务类代码的前提下，绕过业务类代码中的外部调用（或其他会影响测试的调用）。 对于测试方法里直接发起的调用，不应当被Mock。

首先Testable Mock的方法的调用，而不是方法本身。举例来说，假设原本代码是： ```java public String callCommonFunc() { return commonFunc();

跨类做分层测试的情况，如果使用Testable，需要将Mock目标类作为Mock首个参数，同时配合`TestableTool.MOCK_CONTEXT`变量传递额外来源信息实现。 例如要Mock的是`TargetClass`的`String methodToMock(int i, int j)`方法： ```java // Mock目标类不写到MockInvoke注解参数，而是加到方法的首参 @MockInvoke private String methodToMock(TargetClass self, int i, int j) { switch((String)MOCK_CONTEXT.get("TEST_LAYER")) { case "moduel-test": // 调用原方法 return self.methodToMock(i, j); default: //...

这里需要指出，Testable设计的时候主要考虑纯单元测试场景，对单元测试/集成测试混用的情况会有一些额外使用成本（在Mock方法里判断`MOCK_CONTEXT`中的上下文信息）

Testable只有`@EnablePrivateAccess`注解依赖了`sun.jdk`包，只要没有用到这个注解，就可以安全移除。 同时由于引入`testable-all`时候是指定了`test`的，在打工程jar包的时候也不会将`testable-all`和依赖打到产物里。

是个已知的问题，临时绕过方案可以参考Lombok的这个Issue回复 https://github.com/projectlombok/lombok/issues/2681#issuecomment-748616687

`demo`里的代码主要是配合文档的介绍内容，其实最开始Java和Kotlin两个Demo都是用的SpringBoot项目哈，后来为了更聚焦改成不带框架的最简项目了。内部我们有一个做发布回归测试的测试用例大仓库，包含包括Spring在内各种场景的Case，但内容太杂也不太适合做demo。 `mockito`是可以配合使用的，如果有遇到问题，可把具体错误情况发一下。从原理而言TestableMock是直接扫描字节码做Mock替换，框架的注解和其他Mock工具都不会对扫描过程产生影响，只是PowerMock和JMockit这类工具也会对字节码进行改动，有潜在的冲突风险，不建议同时使用。 后续我们补充一个包含Mockito和SpringBoot的实例上来。

跨模块的Mock使用`TestableMock`会有些不符合直觉。先说结论： A模块包含启动类，因此测试需要由A模块发起（应当在A模块编写测试类），同时`TestableMock`的Mock类是不能跨模块引用的，因此需要把相应的Mock类也写到A模块（即使被Mock的调用发生在B模块里）。 举个例子： ``` module-a src main com abc Main.java test com abc MainTest.java def DependMock.java module-b src main com def Depend.java ``` 在模块A中，测试发起类是`com.abc.MainTest`，被测的主要类是`com.abc.Main`，它使用了模块B的`com.def.Depend`类。在测试时需要对`com.def.Depend`类中的某些调用进行Mock，此时应当将Mock类`com.def.DependMock`放到执行测试的模块A里才会生效。 此外跨模块Mock的情况在`TestableMock`中很容易产生为了放置Mock类而增加的孤立包路径，可以考虑使用[包路径映射](https://alibaba.github.io/testable-mock/#/zh-cn/doc/use-package-mapping)。 本质来说，虽然`TestableMock`提供几乎万能的Mock能力，但其最初设定的适用场景主要还是标准的单元测试（每个类有自己的测试类），在跨类跨模块等更偏向集成测试的场景里用起来会相对没那么顺手。