Fan Lin
Fan Lin
Since the image tag is usual generated by CI (e.g. Jenkins), app developer sometimes really doesn't case about what is the next tag number. While the guy who does the...
搜索Istio Gateway配置就可以了，这种材料网络上比较容易找到
待升级istio sdk版本至`v1beta1`
历史原因，在项目开始时候`VirtualService`的最高版本还是`v1alpha3`，会择期评估升级
消息和DB隔离现在主流方案还是在中间件上做手脚，一般的网络Mesh，包括Istio都没法处理这类请求
Gradle我们用得比较少，所以确实没有太多经验。 可以确定的是，在Maven下Testable和Jacoco可以正常共存，且使用Testable不会影响Jacoco覆盖率，原理上来说Gradle应该能达到相同效果。
从原理来讲，两者的字节码修改本身互不影响。 其实问题的原因我大致知道，是因为文档里的配置方法直接覆写了`jvmArgs`参数的值，会导致Jacoco Gradle插件注入的启动参数被替换掉，使得Jacoco插桩没有被执行（因为Jacoco的原理也是字节码注入，所以同样需要修改jvmArgs参数，只是它把这个过程封装到自己的Gradle插件里面了）。 在Maven的pom.xml里是使用`@{argLine}`占位符来引用原始的JVM参数内容，从而确保Testable的参数是被追加而不是覆写原有参数（如果直接覆写同样会导致Jacoco覆盖率跌零，因为没有插桩）。但我不太清楚在Gradle里如何表达参数追加。 @luoleijun 前面已经给了一个思路，是在设置`jvmArgs`参数的时候加上 "-javaagent:${classpath.find { it.name.contains("jacoco.agent") }.absolutePath}" 这部分，来显示加载Jacoco的JavaAgent，但他也提到通过这样方式的Jacoco配置项（比如排除类）无法生效，所以并不是一个完美方案。 另一种可能的解决办法是给Testable也制作一个Gradle插件，正如我们已经提供了Testable Maven插件那样，在插件里实现参数追加会相对容易一些。这件事暂时不在我们的计划内，但如果有开发者愿意贡献相关Gradle插件的PR，我们会非常乐意接纳 : D
一种解决办法是通过在不同的用例里预先设置不同的 `MOCK_CONTEXT ` 的值，然后在Mock方法里读取相应的值来加以区分，`MOCK_CONTEXT `这个特殊的Map会在运行期间自动转换为一个存储在ThreadLocal的线程安全容器。 详见[在Mock方法中区分调用来源](https://alibaba.github.io/testable-mock/#/zh-cn/doc/use-mock?id=_2-%e5%9c%a8mock%e6%96%b9%e6%b3%95%e4%b8%ad%e5%8c%ba%e5%88%86%e8%b0%83%e7%94%a8%e6%9d%a5%e6%ba%90) 从根本上来说，Testable在设计时主要考虑的是每个测试类当中仅需要Mock相应业务内直接调用的方法的标准单元测试（即单元测试仅测单一的”单元类型“），对于单元测试时有跨到其他类的情况，会稍显麻烦。
不会。从原理上来说，Testable只是简单的修改了源码中调用被Mock方法的字节码，将它在运行期改为直接调用相应的Mock方法，不会干扰Jacoco的覆盖率统计。