Fan Lin

已增加`demo/android-demo`示例，可进入改目录通过`./gradlew build`运行。 如需在Android Studio中运行，可根据AS版本相应修改`build.gradle`中的`com.android.tools.build:gradle`依赖版本。

目前声明为接口类型的成员都会被初始化为null，和嵌套层数无关，是一个已知现状，在文档里有说明。这个问题其实是有解法的（生成一个临时类并构造），但暂时没有精力排期开发。

在测试用例里的调用不会被Mock，只有被测类（业务类）源码里的调用才会生效 见文档的[特别说明](https://alibaba.github.io/testable-mock/#/zh-cn/doc/use-mock?id=_4-特别说明)部分

没有遇到过这个问题。JDK 1.8版本里`com.sun.tools.javac`包是在单独的`tools.jar`里的，但IDEA应该可以识别到，如果确实没有识别，搜索这个错误能找到不少可参考的文章，手工设置一下（比如[这篇](https://www.cnblogs.com/jpfss/p/11584995.html)）。从JDK 9开始的版本`com.sun.tools.javac`包都是内置的了，应该不会不存在。 会不会是IDEA指向的`JAVA_HOME`被设置为了JRE的目录而不是JDK目录？

@luyuanwan @workswan 麻烦试试直接在命令行里`mvn clean install`或者`gradle build test`是否可以呢？ 没有现场不太好查，先确认一下是JDK安装的问题还是IDE的问题。

从现象来看应该是与IDE配置有关，确实无法出复现此问题，暂无更多建议

如果对mapper中的方法的 **调用** 是发生在`AServiceImpl`类里的，那么直接在`AServiceImplTest.Mock`类型里定义与目标调用相同前面的Mock方法应该会生效。 但如果实际 **调用** 的代码是写在抽象父类`AbstractService`中的，这种场景属于TestableMock支持得不太好的一种情况，就是被Mock的逻辑不在被测类里，此时需要额外创建一个与父类`AbstractService`绑定的Mock类型`AbstractServiceMock`，放在测试目录与`AbstractService`类相同的包路径下面，然后在`AbstractServiceMock`里定义相应的Mock方法。

TestableMock的Mock定义会被所有测试方法共享，而不是每个测试用例定义自己专用的Mock实现，因此通过调用次数判断返回内容可能不是太通用。对于特定的场景，可以先通过`MOCK_CONTEXT`变量来存储此次。

这个问题本身没有唯一答案，其实主要看测试的目的的做单元回归还是集成回归： - 对于标准的单元测试来说，当测试目标是Service或Component类的逻辑时，DAO层属于对外部依赖的调用，会导致测试慢或离线不可执行，应该通过Mock进行替换。 - 但现实项目中还存在一种情况是使用单元测试框架进行集成测试，典型例子是使用了`@SpringBootTest`注解的测试用例，这种情况下实际测试的是当程序完整启动以后的端到端链路，此时为了保证链路完整性，则会在测试上层逻辑时保留DAO层的功能。 有时候这两种测试也会在一个项目里同时并存，此时若使用`TestableMock`就需要合理运用`MOCK_CONTEXT`对象，或将部分Mock方法的`scope`参数设置为`ASSOCIATED`（详见[Mock的生效范围文档](https://alibaba.github.io/testable-mock/#/zh-cn/doc/scope-of-mock)）。 出于测试稳定性和效率考虑，我会更推荐在非必要的情况下，都统一使用Mock的DAO层进行测试。

挺好的建议，先Mark一下，作为后续版本的备选功能~