Fan Lin

`MOCK_CONTEXT`本质上是一个语法糖，会在运行期间被动态替换为一个存储在当前线程上下文里、由Testable负责维护的Map对象，它的内容会在每个测试用例开始执行前被清空。 在Debug的时候可以直接调用`MockContextUtil.parameters()`方法来获得这个上下文Map对象。在通用方法里也可以用这个方法替代`MOCK_CONTEXT`。

感谢对这个项目的关注。 TestableMock最初的设计主要是希望降低Mock的入门门槛，把需要用到的注解、操作步骤都减少到最少，顺便将我们过去在单元测试中遇到的私有成员访问、参数对象构造等等常见问题一起解决。但从后来推广的情况来看，TestableMock对于比较规范的项目来说（项目结构、测试文件命名、测试粒度等方面），确实能够极大的提高Mock的引入成本，但遇到工程实践原本就做得不够好的项目，反而会用起来很绕，甚至不如传统的Mock工具易用。为了适配一些不规范的场景，TestableMock加入了如`@MockWith`、包路径映射等等复杂的用法，一定程度上逐渐违背初衷，目前此项目已经暂时转入低频维护状态。 关于你提的几个问题。 1. 保障质量的措施有非常多，单元测试主要的目的是确保局部业务逻辑（尤其在边界条件下）的正确性，这只是代码质量里（比较细节）的一个方面。如果是为了提升整体代码质量，推荐从 _“代码评审”_ 和 _“代码安全扫描”_ 这两件事做起。影响代码质量最根本的因素依然在于开发者个人能力、编码习惯和业务经验，_有效的_ 代码评审可以促进开发者之间快速的相互学习进步。除了人工评审，代码扫描能发现不少质量上的漏网之鱼，尤其是 _安全相关_ 的扫描（相比于编码风格、规约一类的扫描而言）对于防范风险的作用更大，建议了解一下阿里云[Codeup产品](https://www.aliyun.com/product/yunxiao/codeup)的相关能力。除此之外，团队内的技术氛围、开发者与测试人员之间的有效沟通、好用的开发&调试&发布工具都会对产出高质量代码很有帮助。 2. 单元测试覆盖应该由开发同学来保障，但是否要把覆盖率作为质量的衡量指标，值得商榷。单元测试写得好，覆盖率会提高，但覆盖率高并不一定单元测试做得就好，在工程能力不足的团队里推行测覆盖率往往反而会导致开发同学编写大量低质量的单测用例。API和UI级别的测试通常可以由专职的测试同学来完成，也可以是开发同学自己做。 3. 差异不大，主要看代码本身是否有复杂的计算逻辑、业务规则或者边界条件，如果有，那就要建议做单元测试。 4. 根据项目的重要程度、复杂程度、开发者技能的熟练程度（以及项目是否强制要求覆盖率数量）而异。譬如一些底层通信编解码类的核心逻辑，业务和单测编写时间可以是1:1，甚至花比业务代码更多的时间在单元测试上。对于一般性的业务，开发者花在单元测试的时间占总编码时间的20%-50%都是正常范围。

我这边实测`springfox-spring-web` 3.0.0版本和TestableMock 0.7.0版本可以共存，没有发现测试用例执行异常

应该是一处BUG，使用`@EnablePrivateAccess`的方式对IDE提示不友好，已经在当前版本文档标为弃用了。 建议统一采用`PrivateAccessor`，在未来版本里会进一步增强`PrivateAccessor`的目标检测能力（防代码重构机制），并移除`@EnablePrivateAccess`注解。

暂时不会做一对多的Mock关联，对于Mock方法复用，建议尽量通过Mock类型之间继承的方式来实现。 在Testable里，被测类、测试类、Mock类之间关联的最佳方式是采用约定命名，在不得已情况下可以用`@MocksWith`注解，但这样会对测试代码的阅读来说其实是不太方便的。如果增加一对多的MockWith关联，代码维护者将更难快速理解哪些调用在测试时存在Mock，无疑会进一步增加阅读维护的成本。

看起来和 #148 是相同的问题，issue-148提交者应该是自己找到原因了，直接关闭issue但没有留下具体说明。 从报错来问题像是项目直接引用了`testable-agent`包，而不是文档建议的`testable-all`。如果单独引用`testable-agent`包，需要至少同时加上`testable-core`包，否则会在测试运行期找不到`com.alibaba.testable.core.util.LogUtil`这个类。

尝试一下显式的添加 testable-core 依赖，是否能解决问题？

粗看起来应该是测试类没有按照 ”被测类+Test“ 约定命名导致Mock的关联没建立起来，可以把测试类的名字改为 ServiceATest，或者使用@MockWith注解来建立Mock关联

@riane2 写了一个简单的参考示例 https://github.com/linfan/testable-spring-demo Testable原理上是和运行框架无关的，不会受Spring、MyBatis或其他依赖影响。如果依然有问题，可以参考[自助问题排查](https://alibaba.github.io/testable-mock/#/zh-cn/doc/troubleshooting)文档。

这个问题在之前的Issue中有被讨论过，需要保留`targetClass`参数主要的原因是Testable允许将目标类放在参数首位（有些Mock方法需要与原对象交互）。 假如参数是可省略的，那么在测试类ATest里看到这个Mock定义 ``` @MockMethod public String bm(B b) { return "bmMock"; } ``` 它既可能是Mock类型B当中的String bm()方法，也可能Mock是A类型当中的String bm(B b)方法，就会产生歧义。