使用fragile框架进行的糟糕的JUnit测试具有脆弱的Thread.sleep()调用。怎么修？
我最近加入了一个小组，有一些严重的JUnit测试问题。一个问题是8分钟长的测试！测试有几个部分；每个部分调用org.springframework.context.ApplicationEventPublisher.publishEvent()，然后调用不同时间的Thread.sleep()，然后测试条件。
这种方法有几个明显的问题，Thread.sleep()调用的时间很脆弱：
- 测试偶尔在繁忙的机器上失败；以及
- 考试失败的时间太长了。
是否可以访问处理这些事件的池进行测试，是否有调用来查看事件级联是否已停止运行？
回答 3
Stack Overflow用户
发布于 2010-12-13 22:52:32
可以通过将此bean id添加到应用程序上下文中来覆盖默认的applicationEventMulticaster。
您可以在此bean上设置一个TaskExecutor，以在多个线程中异步执行事件发布，而不是默认的TaskExecutor。
或者您可以实现您自己的多播程序，它可以打印出哪个事件侦听器花了这么长时间或阻塞了哪些事件、多长时间以及在哪个事件上。这可以帮助你找到8分钟测试的真正问题。
有趣的是，在使用JavaDoc时默认使用的SimpleApplicationEventMulticaster的ApplicationContext声明如下：
默认情况下，调用线程中调用所有侦听器。允许流氓侦听器阻塞整个应用程序的危险，但增加的开销最小。指定一个替代的TaskExecutor，让侦听器在不同的线程中执行，例如从线程池中执行。
Stack Overflow用户
发布于 2010-12-13 21:02:34
值得一提的是，实际上调用外部服务的测试代码是集成测试，而不是单元测试。如果您在这里进行真正的单元测试，您应该用模拟替换这些调用。这样，您就可以更好地控制返回到业务逻辑的值，并测试特定条件。而且，正如您所看到的，这几乎消除了由于外部(非代码)情况而产生的假阳性。显然，这些测试并没有失败，他们期望使用的工具是。
Stack Overflow用户
发布于 2010-12-15 08:46:49
我(有意)避免使用Spring，所以我不确定我能不能帮助解决具体问题，但是仅仅看一下睡眠问题，您就可以使用诸如tempus-fugit (无耻的插件)中的WaitFor之类的东西来为Condition进行投票，而不是“睡眠和希望”。这并不理想，而且通常您的测试方式(如前面所建议的)的改变是可取的，但它确实意味着您得到更细粒度的“等待”，这更有可能避免竞争条件/片状测试，并且通常会加快测试速度。
有关详细信息，请参阅项目的文档，如果您发现它有用，请回发！
https://stackoverflow.com/questions/4433423
复制相似问题
腾讯云开发者
