能否更灵活的引入多个Mock容器

[SnowFlakeLeaf]

目前@MockWith注解只能指定引入一个Mock容器类，并且还会让自身写的内部静态Mock类失效（虽然可以通过静态内部类继承解决，但是多个的情况下Java不支持多继承）。项目较为复杂的情况下，可能需要多个写好的Mock方法被复用（全部写在同一个Mock类中会导致依赖太多反而也很麻烦）。虽然目前提供的例子里引入多个Mock类却需要在同一个包下，实际项目中想做到这一点是比较困难的。因此是否有其他办法引入多个Mock容器类呢？

[linfan]

暂时不计划支持。

从Testable先前推广过程里的反馈来看，比较显著的问题是将Mock与测试用例解耦以后，一方面测试的代码确实会变得更干净，另一方面在阅读测试代码的时候，对于理解哪些地方会被Mock也会变得不太直观。

太过灵活就会带来代码可读性的下降，因此Testable在设计Mock方法复用机制的时候也相对克制。如果一个业务类能关联多个Mock类，再加上继承复用的机制，虽然编写测试的时候会更方便，但在阅读代码的时候会很难快速找到到底有多少方法被Mock了，对于测试代码的长期维护是弊大于利的。

[SnowFlakeLeaf]

感谢您的回答。我十分认同您所说如果允许Mock与测试用例解耦后产生的问题是肯定会广泛出现在各个使用TestableMock的项目中，但我认为作为一个组件，至少应该提供这方面的能力给开发者使用不是吗，我们可以在默认的用法中不建议大家这样做，但我认为提供这方面的能力是很有必要的，就好比Spring中的AOP代理机制，它的不规范滥用使用同样也会带来很多潜在的风险，但至少我们应当提供这方面的能力不是嘛。当然如果有更紧急的需求，我认为这个计划也是可以暂时先搁置的