Master the most popular testing framework for Java, through the Learn JUnit course:
Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Get started with Spring and Spring Boot, through the Learn Spring course:
>> LEARN SPRINGExplore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely β and automatically β with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. Thatβs where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions β one for newcomers and one for experienced users. Youβll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
1. Overview
By default, JUnit runs tests using a deterministic but unpredictable order (MethodSorters.DEFAULT).
In most cases, that behavior is perfectly fine and acceptable. But there are cases when we need to enforce a specific order.
2. Test Methods Ordering in JUnit 5
In JUnit 5, we can use @TestMethodOrder to control the execution order of tests.
We can use our own MethodOrderer, as weβll see later.
Or we can select one of three built-in orderers:
- Alphanumeric Order
- @Order Annotation
- Random Order
2.1. Using Alphanumeric Order
JUnit 5 comes with a set of built-in MethodOrderer implementations to run tests in alphanumeric order.
For example, it provides MethodOrderer.MethodName to sort test methods based on their names and their formal parameter lists:
@TestMethodOrder(MethodOrderer.MethodName.class)
public class AlphanumericOrderUnitTest {
private static StringBuilder output = new StringBuilder("");
@Test
void myATest() {
output.append("A");
}
@Test
void myBTest() {
output.append("B");
}
@Test
void myaTest() {
output.append("a");
}
@AfterAll
public static void assertOutput() {
assertEquals("ABa", output.toString());
}
}
Similarly, we can use MethodOrderer.DisplayName to sort methods alphanumerically based on their display names.
Please keep in mind that MethodOrderer.Alphanumeric is another alternative. However, this implementation is deprecated and will be removed in 6.0.
2.2. Using the @Order Annotation
We can use the @Order annotation to enforce tests to run in a specific order.
In the following example, the methods will run firstTest(), then secondTest() and finally thirdTest():
@TestMethodOrder(OrderAnnotation.class)
public class OrderAnnotationUnitTest {
private static StringBuilder output = new StringBuilder("");
@Test
@Order(1)
void firstTest() {
output.append("a");
}
@Test
@Order(2)
void secondTest() {
output.append("b");
}
@Test
@Order(3)
void thirdTest() {
output.append("c");
}
@AfterAll
public static void assertOutput() {
assertEquals("abc", output.toString());
}
}
2.3. Using Random Order
We can also order test methods pseudo-randomly using the MethodOrderer.Random implementation:
@TestMethodOrder(MethodOrderer.Random.class)
public class RandomOrderUnitTest {
private static StringBuilder output = new StringBuilder("");
@Test
void myATest() {
output.append("A");
}
@Test
void myBTest() {
output.append("B");
}
@Test
void myCTest() {
output.append("C");
}
@AfterAll
public static void assertOutput() {
assertEquals("ACB", output.toString());
}
}
As a matter of fact, JUnit 5 uses System.nanoTime() as the default seed to sort the test methods. This means that the execution order of the methods may not be the same in repeatable tests.
However, we can configure a custom seed using the junit.jupiter.execution.order.random.seed property to create repeatable builds.
We can specify the value of our custom seed in the junit-platform.properties file:
junit.jupiter.execution.order.random.seed=100
2.4. Using a Custom Order
Finally, we can use our custom order by implementing the MethodOrderer interface.
In our CustomOrder, weβll order the tests based on their names in a case-insensitive alphanumeric order:
public class CustomOrder implements MethodOrderer {
@Override
public void orderMethods(MethodOrdererContext context) {
context.getMethodDescriptors().sort(
(MethodDescriptor m1, MethodDescriptor m2)->
m1.getMethod().getName().compareToIgnoreCase(m2.getMethod().getName()));
}
}
Then weβll use CustomOrder to run the same tests from our previous example in the order myATest(), myaTest(), and finally myBTest():
@TestMethodOrder(CustomOrder.class)
public class CustomOrderUnitTest {
// ...
@AfterAll
public static void assertOutput() {
assertEquals("AaB", output.toString());
}
}
2.5. Set Default Order
JUnit 5 provides a convenient way to set a default method orderer through the junit.jupiter.testmethod.order.default parameter.
Similarly, we can configure our parameter in the junit-platform.properties file:
junit.jupiter.testmethod.order.default = org.junit.jupiter.api.MethodOrderer$DisplayName
The default orderer will be applied to all tests that arenβt qualified with @TestMethodOrder.
Another important thing to mention is that the specified class must implement the MethodOrderer interface.
3. Test Methods Ordering in JUnit 4
For those still using JUnit 4, the APIs for ordering tests are slightly different.
Letβs go through the options to achieve this in previous versions as well.
3.1. Using MethodSorters.DEFAULT
This default strategy compares test methods using their hash codes.
In case of a hash collision, the lexicographical order is used:
@FixMethodOrder(MethodSorters.DEFAULT)
public class DefaultOrderOfExecutionTest {
private static StringBuilder output = new StringBuilder("");
@Test
public void secondTest() {
output.append("b");
}
@Test
public void thirdTest() {
output.append("c");
}
@Test
public void firstTest() {
output.append("a");
}
@AfterClass
public static void assertOutput() {
assertEquals(output.toString(), "cab");
}
}
When we run the tests in the class above, we will see that they all pass, including assertOutput().
3.2. Using MethodSorters.JVM
Another ordering strategy is MethodSorters.JVM.
This strategy utilizes the natural JVM ordering, which can be different for each run:
@FixMethodOrder(MethodSorters.JVM)
public class JVMOrderOfExecutionTest {
// same as above
}
Each time we run the tests in this class, we get a different result.
3.3. Using MethodSorters.NAME_ASCENDING
Finally, this strategy can be used for running tests in their lexicographic order:
@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class NameAscendingOrderOfExecutionTest {
// same as above
@AfterClass
public static void assertOutput() {
assertEquals(output.toString(), "abc");
}
}
When we run the tests in this class, we see they all pass, including assertOutput(). This confirms the execution order that we set with the annotation.
4. Test Classes Ordering Using @TestClassOrder
We can also control the execution order of test classes using the @TestClassOrder.
Junit 5 comes with a ClassOrderer interface, similar to MethodOrderer. We can use it in the same manner as the method ordering in the previous sections. ClassOrderer supports the following ways to order tests:
- ClassName β sorts classes alphanumerically, based on their names
- DisplayName β sorts classes alphanumerically based on their display names
- OrderAnnotation β sorts classes based on the @Order annotation
- Random β sorts classes randomly
- Custom Order β sorts classes based on the custom sorting order
4.1. Using ClassName
It enables the execution of classes in alphabetical order according to their fully qualified class names. This is the default ordering mechanism based on the actual class name in the code.
Letβs define some test classes that weβll use to run different tests:
public class TestA {
@Test
void testA() {
System.out.println("Running TestA");
}
}
public class TestB {
@Test
void testB() {
System.out.println("Running TestB");
}
}
public class TestC {
@Test
void testC() {
System.out.println("Running TestC");
}
}
To use @TestClassOrder, the classes need to be part of the same hierarchy. For that, by using @Nested and inheritance, we create a flexible structure that allows us to group the tests logically within a suite:
@TestClassOrder(ClassOrderer.ClassName.class)
public class ClassNameOrderUnitTest {
@Nested
class C extends TestC {}
@Nested
class B extends TestB {}
@Nested
class A extends TestA {}
}
In the above example, we created a parent test suite, ClassNameOrderUnitTest, which acts as a container for the test classes.
The @TestClassOrder(ClassOrderer.ClassName.class) allows us to enforce alphabetical order. After running the program, the output will be:
Running TestA
Running TestB
Running TestC
4.2. Using DisplayName
The ClassOrderer.DisplayName orders classes by their display names if explicitly set. If we havenβt set any display name, JUnit falls back to the class name.
In the below example, weβll set the @DisplayName annotations on the nested wrapper classes and not on the original test class TestA, TestB, and TestC:
@TestClassOrder(ClassOrderer.DisplayName.class)
public class DisplayNameOrderUnitTest {
@Nested
@DisplayName("Class C")
class Z extends TestC {}
@Nested
@DisplayName("Class B")
class A extends TestA {}
@Nested
@DisplayName("Class A")
class B extends TestB {}
}
For the above program, JUnit will sort these display names alphabetically. The sorted order of display names will be βClass Aβ, βClass Bβ, and βClass Cβ, which leads us to the below output:
Running TestB
Running TestA
Running TestC
4.3. Using OrderAnnotation
The @Order annotation allows us to explicitly define the order in which test classes are executed within a test suite. Itβs useful when we want to have some explicit control over execution order or need to run tests in a specific sequence.
In the below example, the @Order annotation specifies the priority for the nested classes:
@TestClassOrder(ClassOrderer.OrderAnnotation.class)
public class OrderAnnotationUnitTest {
@Nested
@Order(3)
class A extends TestA {}
@Nested
@Order(1)
class B extends TestB {}
@Nested
@Order(2)
class C extends TestC {}
}
The classes with lower @Order values will be executed first. Hence, we get the below output:
Running TestB
Running TestC
Running TestA
4.4. Random
Sometimes, we want to run tests in random order to detect dependencies between tests. This allows us to ensure that our tests donβt rely on the order of execution.
ClassOrderer.Random.class allows us to configure the suite to randomize the execution of test classes. This randomness will be applied each time the test suite run:
@TestClassOrder(ClassOrderer.Random.class)
public class RandomOrderUnitTest {
@Nested
class C extends TestC {}
@Nested
class B extends TestB {}
@Nested
class A extends TestA {}
}
When the above test is is executed, the output will be in a random order, varying with each run.
Run 1 output:
Running TestA
Running TestC
Running TestB
Run 2 output:
Running TestC
Running TestA
Running TestB
4.5. Using a Custom Order
We can implement our own ClassOrderer to define ordering logic based on criteria such as metadata, class name length, configuration, etc. The ClassOrderer interface allows us to define custom logic to sort test classes based on a specific criteria.
Letβs implement a custom ClassOrderer that orders test classes based on the length of their class names:
public class CustomClassOrderer implements ClassOrderer {
@Override
public void orderClasses(ClassOrdererContext context) {
context.getClassDescriptors().sort(
Comparator.comparingInt(descriptor ->
descriptor.getTestClass().getSimpleName().length()
)
);
}
}
Letβs use CustomClassOrderer to sort test classes based on the length of their class names. The sorting order will be shortest to longest:
@TestClassOrder(CustomClassOrderer.class)
public class CustomOrderUnitTest {
@Nested
class Longest extends TestA {}
@Nested
class Middle extends TestB {}
@Nested
class Short extends TestC {}
}
The output is ordered by the length of the class names i.e. Longest, Middle and Short:
Running TestC
Running TestB
Running TestA
Since Short has the shortest name among these classes, the test runner executes it first, resulting in the output βRunning TestCβ appearing first. Subsequently, the test runner executes the Middle and Longest class in order.
5. Conclusion
In this quick article, we went through the ways of setting the execution order available in JUnit.
