用户中心

你好，已添加

你好，git上的项目都是可以直接运行的，包括maven编译，你可以先和自己的项目对照一下，检查下是否少了pom依赖，或者提供更详细的报错信息，我好帮你定位问题

你是要mock掉http的rest模板请求吗？我理解就是正常的mock就行了，如果有什么问题可以提供下代码，我帮你看下

这个感觉跟用什么单测框架无关，目前我的文章都是基于单元测试，即当前类中的某个方法测试，所以不关心是不是http的请求，比如一般项目中都会封装个HttpUtils的工具类，如果你的代码中有调用HttpUtils的方法，直接mock掉就行了。

Spock2.X是基于Junit5,你们项目使用的是junit5吗？(junit5和4差异蛮大的，因为我们项目大部分都是junit4的，我了解下5的使用情况吧)

迟复为歉！如文中所述Spy的例子：methodA内部调用了methodB，但这两个方法属于同一个类MyClass，所以不存在跨层调用（当然如果是跨层调用的话建议使用mock或stub避免，否则就超出单元测试的范畴了，这一点你说的对），我举的Spy场景是说，同一个类中，我要测试methodA方法，但methodA内部调用了methodB，而我又不想测试methodB，这种场景。 这种场景为什么有坏味道呢？因为我觉得正常情况你测试了methodA方法，那么methodA方法内部调用的当前类的其他方法（比如methodB）都应该被测试到，这样才能保证单测的覆盖率，除非说之前已经有一个方法比如methodC内部已经测试过methodB了（但这种情况下其实也没必要spy掉methodB）

迟复为歉，谢谢你的反馈，确实存在这个问题，原因是Groovy和powermock在实现原理上的差异导致的不兼容问题，可以使用stub代替when方法，或使用@compileStatic注解，详细用法可以参考这篇文章：https://javakk.com/2038.html

谢谢肯定

抱歉，这么久才回复你的消息，感谢你的提问，这个问题是这样的，主要是"Future future = executor.submit()",提交线程池的这个操作，在极限情况下(我们生产环境QPS>30)，时是会出现的，本地也能模拟出来，executor.submit()返回的是future，提交线程池的主线程也是从tomcat线程池里的任务，即前端的请求线程，当多个主线程去调用阻塞队列里的入队api时，势必存在竞争的问题，比如linkedBlockQueue的读写锁资源，在这种极端情况下线程池判断线程数是否已满执行拒绝策略时，还是会出现延迟的情况，以前在oracle官方看到过这样的问题描述，所以最重要的还是不要使用caller.run让主线程执行提交线程池任务的拒绝策略(当然也要看具体场景，当我们这种IO型业务基本不需要)