Feature request: add java.time.Duration support to org.junit.rules.Timeout

[kluever]

Representing durations as longs can easily lead to unit mismatch problems.
Representing durations as long, TimeUnit pairs can require plumbing 2 values through multiple layers (and can suffer from unit mismatch or truncation issues).

Could proper java.time.Duration support be added to the Timeout class?

(If this should be filed under junit5, please let me know and I'll open it there.)

[marcphilipp]

JUnit Jupiter is about to add support for "declarative" timeouts using a @Timeout annotation on test classes or methods (see User Guide for details). It also uses the long, TimeUnit combination because Durations cannot be expressed in annotations. In addition, it allows to declare timeouts globally, i.e. to be applied for all tests, using a configuration parameter (which can be specified using a properties file or a system property) in a custom format, e.g. 5 s.

@kluever How do you currently do the plumbing to pass the duration through multiple layers?

[carl-mastrangelo]

@marcphilipp does that work with DisableOnDebug ?

[Tibor17]

In the API architecture perspective this is caled value object. That means both values long and TimeUnit cannot be safely decouled. Using java.time.Duration makes sense to me as this is the wrapper and good value object in this JUnit 4.

[Tibor17]

@marcphilipp
Not in JUnit5 but in yes JUnit4 because org.junit.rules.Timeout is not annotation. So this can be nice here.

[kluever]

Re: "How do you currently do the plumbing to pass the duration through multiple layers?"

I'm not sure I fully understand the question, but in order to use a long, TimeUnit pair, you need to pass both variables through all layers of your application. With Duration, you only need to pass 1 variable.

[marcphilipp]

How do you call JUnit so that there are layers around it?

[marcphilipp]

JUnit 4 is compatible with Java 5 and will stay that way. Thus, adding support for Duration would be rather involved, if feasible at all.