Why does Gradle say "There were failing tests" when the test report shows no test failures?

huangapple go评论79阅读模式
英文:

Why does Gradle say "There were failing tests" when the test report shows no test failures?

问题

我以前遇到过类似的问题,但上次至少有一些测试类无法初始化或类似的情况。这次,Gradle 显示:

任务::foo-bar:liveTest 失败

构建失败:发生异常。

* 出现了什么问题:
执行任务 ':foo-bar:liveTest' 失败。
> 存在失败的测试。请参阅报告:file:///C:/Users/...

但是 CI 服务器 TeamCity 在此构建中未显示任何测试失败。即使重新在本地机器上运行失败的 Gradle 任务以查看报告时,JUnit 报告也未显示任何测试失败或错误!测试中也没有以错误级别记录的内容,也没有以不符合预期的警告级别记录的内容。

可能的问题是什么?我该如何调试这个问题?

英文:

I have had a similar problem before, but last time there were at least some test classes that failed to initialize or something like that. This time, Gradle says

Task :foo-bar:liveTest FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':foo-bar:liveTest'.
> There were failing tests. See the report at: file:///C:/Users/...

But the CI server, TeamCity, shows no test failures for this build. And even the JUnit report, when I re-run the failing Gradle task on my local machine to see that report, shows no test failures or errors! There is also nothing logged at ERROR level from the tests, and nothing logged at WARN level that I wouldn't expect to see, either.

What could be the problem? How can I debug this?

答案1

得分: 4

--debug作为命令行参数传递给gradle :foo-bar:liveTest后显示如下:

10:52:10.894 [DEBUG] [TestEventLogger]         Caused by:
10:52:10.894 [DEBUG] [TestEventLogger]         java.lang.IncompatibleClassChangeError: 

该错误指向项目中的一个类,而不是依赖中的类,这通常意味着一个本应该被 Gradle 重新编译但实际上没有被重新编译的类。然而,执行 Gradle 清理并没有解决问题。

最终问题的原因与此链接中描述的情况相同,尽管没有涉及 Spring Boot。

英文:

Passing --debug as a command-line argument to gradle :foo-bar:liveTest showed that it was:

10:52:10.894 [DEBUG] [TestEventLogger]         Caused by:
10:52:10.894 [DEBUG] [TestEventLogger]         java.lang.IncompatibleClassChangeError: 

referring to a class in the project - not in the dependencies - which would usually indicate that a class that should have been recompiled by Gradle had not, in fact, been recompiled. However, a Gradle clean did not fix the problem.

The problem turned out to be equivalent to this, although no Spring Boot was involved.

答案2

得分: 0

堆空间耗尽是另一个常见原因。如果您开始查看测试输出,您可能会发现一个名为 build/reports/tests/test/classes/Gradle#20Test#20Executor#201.html 的文件(末尾的数字会变化),最终揭示了这个问题:

org.gradle.api.internal.tasks.testing.TestSuiteExecutionException: 无法完成 Gradle 测试执行器 1 的执行。
        at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:63)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
        at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
        at com.sun.proxy.$Proxy2.stop(Unknown Source)
        at org.gradle.api.internal.tasks.testing.worker.TestWorker.stop(TestWorker.java:133)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
        at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.OutOfMemoryError: Java 堆空间
英文:

Running out of heap space is another common cause of this. If you start poking around in the test output, you may find a file named build/reports/tests/test/classes/Gradle#20Test#20Executor#201.html (number at the end will vary) which finally reveals the issue:

org.gradle.api.internal.tasks.testing.TestSuiteExecutionException: Could not complete execution for Gradle Test Executor 1.
        at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:63)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
        at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
        at com.sun.proxy.$Proxy2.stop(Unknown Source)
        at org.gradle.api.internal.tasks.testing.worker.TestWorker.stop(TestWorker.java:133)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
        at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.OutOfMemoryError: Java heap space

huangapple
  • 本文由 发表于 2020年9月19日 16:35:11
  • 转载请务必保留本文链接:https://go.coder-hub.com/63966833.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定