Change in behavior for Timeout Rule in 4.12

[busbey]

In versions 4.7 through 4.11 setting up a Timeout Rule with a value of 0 would result in no timeout. e.g.

public class MyTest {

  @Rule
  Timeout probablyTimeout = new Timeout(NumberUtils.toInt(System.getProperty("test.timeout")));

  @Test
  public void checkSomethingThatTakesAwhile() {
    // ...
  }
}

In this case, commons-lang's toInt will default to 0 for unparseable or empty strings, which Timeout will then interpret as "never timeout". This behavior was a result of FailOnTimeout relying on Thread.join(timeout), which has a contract of 0 meaning "wait forever". This makes it behave the same as the Test annotation's timeout parameter.

In 4.12 FailOnTimeout switched to using FutureTask.get(timeout). That method treats non-positive timeouts to mean "timeout right now".

So when updating to JUnit 4.12, the above example will suddenly start failing if it relies on the 0 timeout behavior to allow an external system to handle test timeout in some cases, e.g. while using Jenkins for CI.

This puts it at odds with both the previous behavior and the method timeout annotation.

[kcooney]

ould you send us a pull request that fixes this? I would like to keep using FutureTask, so we could just add a speacial case that treats zero as MAX_INT

[mcqueenorama]

Is there a workaround for this? I see no releases that include this patch.

[kcooney]

This was fixed in c52397d. Apparently the fix didn't get into the 4.13 release notes. I'll reopen the bug as a reminder.