gpt4 book ai didi

java - Spock 在 "when" block 中运行 Platform.runLater() 时出现计时问题

转载 作者:行者123 更新时间:2023-12-01 17:03:17 31 4
gpt4 key购买 nike

如果必须在 JavaFX 线程中调用某个方法,那么我似乎必须在 when block 中执行以下操作:

... setup ...
// def throwable

when:
Platform.runLater( new Runnable(){
@Override
void run() {
// try {
log.debug "in runnable, calling run method ..."
someObject.methodWhichMustRunInJavaFXThread()
log.debug "... run method finished normally"
// }catch( Throwable t ){
// log.error( t.message, t )
// throwable = t
// }
}
})
WaitForAsyncUtils.waitForFxEvents()
log.debug "waitForFXEvents ended..."
// if throwable != null
// throw throwable
/* NB it appears that re-throwing the Throwable like this after waitForFxEvents
is probably the only way to bring it to the developer's attention!
PS I added this re-throwing idea only a few hours after submitting the question. I am
currently monitoring things to find whether this in fact solves the problem */

then:
// throwable == null
/* in fact this seems to be a rather naive check: from my experimentation,
regardless of whether caught in the above catch clause, it appears that if a throwable
is thrown in `run`, although "invocation counting tests" are performed in the "then"
block, this sort of "static" equality check will never be performed in the "then" block
*/
... other verifications...

但我间歇性地发现,如果在 run 方法中抛出异常,这种技术可能会导致后续测试失败的可怕泄漏。我认为 try catch 任何此类 throwables(如上面的代码所示,如​​果取消注释所有注释行)可能会解决问题,但实际上不能:在 run 中抛出一个 throwable,并由catch 子句,仍然可以归因于后面的方法!

这是一种误导性 Spock 失败输出的示例:尽管此 NPE 是在之前的测试方法中的 Platform.runLater( ... ) 中抛出的(实际上是在完全不同的测试方法中)文件initial_load_testing.groovy中的规范),此失败实际上归因于恰好在其之后某个任意时间进行的测试。

注意提到“延迟异常”...

java.lang.RuntimeException: java.lang.NullPointerException: Cannot invoke method setRoot() on null object
at org.testfx.util.WaitForAsyncUtils.---- Delayed Exception: (See Trace Below) ----(WaitForAsyncUtils.java:0)
Caused by: java.lang.NullPointerException: Cannot invoke method setRoot() on null object
at core.FileHandlingFramework.tryToLoadFile(filehandlingframework.groovy:83)
at core.StdFileHandlingFrameworkTemplate.tryToOpenFile(stdfilehandlingframeworktemplate.groovy:97)
at core.App.start(main.groovy:120)
at core.AppStdSpec2$1.run(initial_load_testing.groovy:92)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
at com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(GtkApplication.java:277)
at java.base/java.lang.Thread.run(Thread.java:834)

我觉得奇怪的是,准确地说,我允许 JavaFX 线程事件通过 WaitForAsyncUtils.waitForFxEvents() “冒泡”...但似乎以某种方式抛出可抛出的有时可以在 waitForFXEvents() 方法结束后被 Spock 框架检测到。

这个问题有解决办法吗?这种现象的间歇性是一个真正的问题。

最佳答案

暂时,以下解决方案似乎可以工作,方法是在 when block 结束之前重新抛出 FX 线程中捕获的任何异常:

void executeInFXThreadAndWait( def closure, def ... params ){
Throwable fXThrowable
Platform.runLater({
try {
closure(params)
}catch( Throwable t ){
if( t.message != 'exit' ) {
log.error(t.message, t)
fXThrowable = t
}
}
})
WaitForAsyncUtils.waitForFxEvents()
if( fXThrowable != null ){
// add calling trace so fail trace identifies Specification line concerned
fXThrowable.stackTrace += Thread.currentThread().stackTrace
throw fXThrowable
}
}

用法(App 扩展Application):

...
def myClosure = { args ->
App.instance.start( args[ 0 ] )
}
...

when:
TestUtilities.instance.executeInFXThreadAndWait( myClosure, mockStage )

then:
...

注意,关于测试“退出”的问题是,有时我会故意在测试中抛出异常,以从需要验证的内容已经验证过的方法中“弹出”。如果 Throwable 的消息是“退出”,它将被忽略。

假设:我在不知道的情况下猜测 Spock 框架能够检测异常是否已被“处理​​”,并且如果像这样重新抛出异常,框架将不会跟进“延迟异常” ”。欢迎 Spock 专家提出意见。

稍后
几天后:结论似乎是这有所改善。然而,在没有任何明显的可预测性或一致性的情况下,仍然可能会发生由于一个规范和功能在另一规范和功能下报告而失败的情况。每次发生这种情况时,都会再次运行相同的测试,而不会出现此类虚假错误。

我相信 Spock 并没有声称能够处理并发编程。很高兴知道其他人在 when block 中执行 Platform.runLater 时是否经历过这种现象。

关于java - Spock 在 "when" block 中运行 Platform.runLater() 时出现计时问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/61484450/

31 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com