blocks|key|1969889|text|值得一提的是，实际上调用外部服务的测试代码是集成测试，而不是单元测试。如果您在这里进行真正的单元测试，您应该用模拟替换这些调用。这样，您就可以更好地控制返回到业务逻辑的值，并测试特定条件。而且，正如您所看到的，这几乎消除了由于外部(非代码)情况而产生的假阳性。显然，这些测试并没有失败，他们期望使用的工具是。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1969890|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Worth mentioning is that test code that actually calls external services are integration tests and not unit tests. If you're truly unit testing here you should replace those calls with mocks. That way you can better control the values returned to your business logic and test for specific conditions. Also, as you've seen, this all but eliminates false positives due to external (non-code) situations. Obviously these tests aren't failing, the facility they expect to use is.

blocks|key|2327490|text|可以通过将此bean+id添加到应用程序上下文中来覆盖默认的applicationEventMulticaster。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2327491|您可以在此bean上设置一个TaskExecutor，以在多个线程中异步执行事件发布，而不是默认的TaskExecutor。|2327492|或者您可以实现您自己的多播程序，它可以打印出哪个事件侦听器花了这么长时间或阻塞了哪些事件、多长时间以及在哪个事件上。这可以帮助你找到8分钟测试的真正问题。|2327493|有趣的是，在使用JavaDoc时默认使用的SimpleApplicationEventMulticaster的ApplicationContext声明如下：|2327494|默认情况下，调用线程中调用所有侦听器。允许流氓侦听器阻塞整个应用程序的危险，但增加的开销最小。指定一个替代的TaskExecutor，让侦听器在不同的线程中执行，例如从线程池中执行。|blockquote|BOLD|2327495|entityMap^0|U|R|0|0|0|0|J|F|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|W|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|X|8|@$9|Y|A|Z|B|O]]|D|@]|E|$]]|$1|P|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|Q|$]]

You can overwrite the default <code>applicationEventMulticaster</code> by adding this bean id to your application context. 

Instead of the default <code>SimpleApplicationEventMulticaster</code>, you could set a TaskExecutor on this bean to perform the event publishing asynchronously in multiple threads. 

Or you could implement your own multicaster, which prints out which event listener took so long or was blocking, for how long and on which events. That could help you to track down the real problem of the 8-Minute-Testcase.

Interestingly, the JavaDoc of the SimpleApplicationEventMulticaster, which is used by default by Spring when you are using ApplicationContext, states the following:

<blockquote>
 By default, all listeners are invoked in the calling thread. This allows the danger of a rogue listener blocking the entire application, but adds minimal overhead. Specify an alternative TaskExecutor to have listeners executed in different threads, for example from a thread pool.
</blockquote>

blocks|key|1969964|text|我(有意)避免使用Spring，所以我不确定我能不能帮助解决具体问题，但是仅仅看一下睡眠问题，您就可以使用诸如tempus-fugit+(无耻的插件)中的WaitFor之类的东西来为Condition进行投票，而不是“睡眠和希望”。这并不理想，而且通常您的测试方式(如前面所建议的)的改变是可取的，但它确实意味着您得到更细粒度的“等待”，这更有可能避免竞争条件/片状测试，并且通常会加快测试速度。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1969965|有关详细信息，请参阅项目的文档，如果您发现它有用，请回发！|1969966|entityMap|0|LINK|mutability|MUTABLE|url|http://tempusfugitlibrary.org/documentation/time/waiting/^0|25|7|2J|9|0|D|2|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@]|D|@$9|V|A|W|1|X]]|E|$]]|$1|H|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

I (intentionally) avoid Spring so I'm not sure I can help with the specifics but just looking at the sleep issue, you can use something like <code>WaitFor</code> in tempus-fugit (shameless plug) to poll for a <code>Condition</code> rather than "sleep and hope". It's not ideal and usually a change in the way you test (as suggested before) is preferable but it does mean you get finer grained "waits" which are more likely to avoid race-conditions / flaky tests and generally speed up the test.

See the project's <a href="http://tempusfugitlibrary.org/documentation/time/waiting/" rel="nofollow">documentation</a> for details and post back if you find it useful!

I have recently joined a group with some severe JUnit testing issues. One problem is an 8 minute long test! The test has several sections; each makes calls to org.springframework.context.ApplicationEventPublisher.publishEvent()
followed by Thread.sleep() of various amounts of time, then tests conditions.

There are several obvious problems with this approach, the timing of the Thread.sleep() calls is fragile:

<ul>
<li>tests occasionally fail on busy machines; and</li>
<li>tests take far too long when they do not fail.</li>
</ul>

Is the pool upon which these events are handled accessible for testing and is there a call to see if the event cascade has quiesced?

Poor JUnit test using springframework has fragile Thread.sleep() calls. How to fix?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我最近加入了一个小组，有一些严重的JUnit测试问题。一个问题是8分钟长的测试！测试有几个部分；每个部分调用org.springframework.context.ApplicationEventPublisher.publishEvent()，然后调用不同时间的Thread.sleep()，然后测试条件。这种方法有几...

问使用fragile框架进行的糟糕的JUnit测试具有脆弱的Thread.sleep()调用。怎么修？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用fragile框架进行的糟糕的JUnit测试具有脆弱的Thread.sleep()调用。怎么修？EN