CODEWITHSUNDEEP
javajunitdeterministic
BackToBasics
BackToBasics

Reputation: 152

JUnit excecution order

So i found a method to sort junit tests within a class with @FixMethodOrder but reading the documentation i came across with something i dont understand:

The default order of execution of JUnit tests within a class is deterministic but not predictable. The order of execution is not guaranteed for Java 7 (and some previous versions), and can even change from run to run, so the order of execution was changed to be deterministic (in JUnit 4.11)

During my studies i have never met with any algorithm or system both deterministic and nonpredictible. Only systems i could imagine that whould fit into this is complex systems like weather or nature in general, because for those we dont have any concrete algoritm for now, but Junit? Can someone explain what does Junit doc refer?

Thanks, Mark

Upvotes: 2

Views: 334

Answers (1)

sisyphus
sisyphus

Reputation: 6392

All its saying is that the algorithm is well-defined but that it depends on too many complex, non-controllable factors for you as a developer to usefully predict or rely on the order.

According to the documentation of java.lang.Class the JVM is free to return the methods from the getMethods() method in any order. And so the first thing to be aware of is that the underlying algorithm may change between JVM releases / implementations.

The order in which methods are laid out in a classfile is not strictly defined in the JLS so the same class compiled by different compilers may end up with slightly different method orders which the same JVM might return different method orders for, even though the class is otherwise the same.

And within the JVM the class information may be stored in ways which are not guaranteed to return a consistent order, and which may even be dependent on where the JVM is in its lifecycle. As an example, imagine every method was stored as a java.lang.Method object and that java.lang.Class stored them all in a Set, with the order of getMethods() being dependent on the order of the objects in the Set - essentially random (or pseudo-random) due to hashing.

Although the JVM does not work exactly like that it does use implementation-dependent data structures which make it difficult to predict the return order of a method like java.lang.Class.getMethods() and impossible to guarantee consistency of between JVM implementations and/or releases. So, if you look at the OpenJDK implementation of java.lang.Class you'll see that the getMethods() method is implemented in terms of a number of native methods. Once you're into native code you are depending on very implementation-specific factors such as memory addresses and, as the documentation implies, the JVM is not going to ensure that their effects are entirely hidden from you.

Upvotes: 3

Related Questions