Build successful while test fails

Old Forum
1

Sorry, the buffer of my terminal got lost, and I only have this left. The rest can be found here: https://twitter.com/epragt/status/512163337430638592

at com.esotericsoftware.kryo.io.Input.readByte(Input.java:255)
 at org.gradle.messaging.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:64)
 at org.gradle.messaging.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:53)
 at org.gradle.messaging.remote.internal.inet.SocketConnection.receive(SocketConnection.java:83)
 ... 5 more
  8 tests completed, 1 failed
:check
:build
  BUILD SUCCESSFUL

This happened while running a test, the test executor stopped, giving the above stacktrace. When doing another ‘gradlew build’, the execution was immediately successful, even though I have one failing test case, which showed up again after doing a ‘gradlw clean build’.

2

I will try to reproduce the problem on the simplest setup: gradle + java-app + junit. Then we go step by step to isolating the problem.

3

I created the simplest project, allowing to test gradle + junit: https://github.com/akhikhl/testtest

Please do: - ‘git clone https://github.com/akhikhl/testtest.git’ - ‘cd testtest’ - ‘gradle build’

Does it show “BUILD FAILED” for you?

4

Erik,

Is your code public? If not, would it be possible to make it public? We will need to have a look at it to be able to investigate.

Based on what information is available in the stacktrace I can tell that the buffer underflow you’re seeing is some kind of a problem with communication between the build process and the worker process running the tests. Having a look at the code will probably reveal more.

5

Does com.esotericsoftware.kryo.io.Input communicate to gradle classes? If not, maybe it is using the same ports?

6

Hi guys, I’m actually able to reproduce it, in a very nasty way.

I have a project with a failing test. What I also have, is another test, with a Thread.sleep(10000) in it, which first opens a Swing console, and then starts waiting. I forgot that the code was there, and thought my system was hanging or something. So what I did was:

  1. ./gradlew build 2) the first test fails 3) the second test seems to hang, so I pressed CMD+Q 4) result:
nl.jworks.color.DominantColorFinderTest > testTwoColors FAILED
    java.lang.AssertionError at DominantColorFinderTest.java:27
  8 tests completed, 1 failed
  BUILD SUCCESSFUL

I can share the code, but I rather not put it on Github, because right now it’s not hubworthy.

7

Do you get the same stacktrace from above? The one with the org.gradle.messaging.remote stuff in it? I bet what’s happening is the worker running the tests is dying before it sends the results back to the main thread. That’s then getting interpreted as ‘no errors’ which is marking the build as success.

8

Hi John,

Also thanks for the reply! Yes, I get indeed the same error. It makes sense that it works like that, but from a user perspective, it’s a bit weird. I mean, I assume the build systems knows that it kicked off the test to start with, and interpreting ‘no results’ as ‘everything is fine’ is a bit unexpected, but I might be totally having the wrong idea here. Anyway, it’s not so important, though I’m curious if there are other scenarios where this might be a problem. If not, then just close this issue, I’d say.

9

I agree that that is odd and if that is in fact what is happening, it’s probably a bug that should be fixed. The more curious question is why you’re test seems to be killing the worker.

10

I think that’s because I am not killing my Swing UI, which is popping up, but instead it seems I’m killing GradleWorkerMain.

11

You doing a System.exit(0) or something like that?

12

Something like that. Cmd+Q, which I think is (almost?) equal to System.exit(). I did it because I thought my test was hanging, then this happened.