If you want to learn how you can work smarter and save time when you are writing tests with JUnit 5, you should take a look at my Introduction to JUnit 5 course. It has 24 lessons, 47 exercises, and 13 quizzes.
This blog post describes how we can write nested tests with JUnit 5. After we have finished this blog post, we:
- Can create nested test classes.
- Know how we can add setup, teardown, and test methods to nested test classes.
- Understand the invocation order of setup, teardown, and test methods.
Let's start by taking a look at our test class.
Introduction to Our Test Class
The previous part of this tutorial described how we can use setup and teardown methods, and add test methods to our test classes. Also, we wrote a simple test class and added all setup and teardown methods to the created class.
The source code of our test class looks as follows:
import org.junit.jupiter.api.*; @DisplayName("JUnit 5 Nested Example") class JUnit5NestedExampleTest { @BeforeAll static void beforeAll() { System.out.println("Before all test methods"); } @BeforeEach void beforeEach() { System.out.println("Before each test method"); } @AfterEach void afterEach() { System.out.println("After each test method"); } @AfterAll static void afterAll() { System.out.println("After all test methods"); } }
Next, we will add nested setup, teardown, and test methods to our test class.
Writing Nested Tests
When we write nested tests with JUnit 5, we have to create a nested test class hierarchy that contains our setup, teardown, and test methods. When we add nested test classes to our test class, we have to follow these rules:
- All nested test classes must be non-static inner classes.
- We have to annotate our nested test classes with the
@Nested
annotation. This annotation ensures that JUnit 5 recognizes our nested test classes. - There is no limit for the depth of the class hierarchy.
- By default, a nested test class can contain test methods, one
@BeforeEach
method, and one@AfterEach
method. - Because Java doesn't allow
static
members in inner classes, the@BeforeAll
and@AfterAll
methods don't work by default.
- We should annotate our nested test classes with the
@DisplayName
annotation because it allows us to replace technical names with a sentence that describes the purpose of the nested test class. - If you want to use the
@BeforeAll
and@AfterAll
methods in nested test classes, you should take a look at the JUnit 5 User Guide.
Let's add a few inner classes to our test class. The idea of this exercise is to demonstrate the invocation order of setup, teardown, and test methods. We can add the required inner classes to our test class by following these steps:
First, we have to add a new inner class called A
to our test class and annotate the inner class with the @Nested
annotation. After we have created the A
class, we have to add one setup, teardown, and test method to the created inner class.
After we have added this inner class to the JUnit5NestedExampleTest
class, the source code of our test class looks as follows:
import org.junit.jupiter.api.*; @DisplayName("JUnit 5 Nested Example") class JUnit5NestedExampleTest { @BeforeAll static void beforeAll() { System.out.println("Before all test methods"); } @BeforeEach void beforeEach() { System.out.println("Before each test method"); } @AfterEach void afterEach() { System.out.println("After each test method"); } @AfterAll static void afterAll() { System.out.println("After all test methods"); } @Nested @DisplayName("Tests for the method A") class A { @BeforeEach void beforeEach() { System.out.println("Before each test method of the A class"); } @AfterEach void afterEach() { System.out.println("After each test method of the A class"); } @Test @DisplayName("Example test for method A") void sampleTestForMethodA() { System.out.println("Example test for method A"); } } }
Second, we have to add a new inner class called WhenX
to the A
class and annotate the inner class with the @Nested
annotation. After we have created the WhenX
class, we have to add one setup, teardown, and test method to the created inner class.
After we have added this inner class to the A
class, the source code of our test class looks as follows:
import org.junit.jupiter.api.*; @DisplayName("JUnit 5 Nested Example") class JUnit5NestedExampleTest { @BeforeAll static void beforeAll() { System.out.println("Before all test methods"); } @BeforeEach void beforeEach() { System.out.println("Before each test method"); } @AfterEach void afterEach() { System.out.println("After each test method"); } @AfterAll static void afterAll() { System.out.println("After all test methods"); } @Nested @DisplayName("Tests for the method A") class A { @BeforeEach void beforeEach() { System.out.println("Before each test method of the A class"); } @AfterEach void afterEach() { System.out.println("After each test method of the A class"); } @Test @DisplayName("Example test for method A") void sampleTestForMethodA() { System.out.println("Example test for method A"); } @Nested @DisplayName("When X is true") class WhenX { @BeforeEach void beforeEach() { System.out.println("Before each test method of the WhenX class"); } @AfterEach void afterEach() { System.out.println("After each test method of the WhenX class"); } @Test @DisplayName("Example test for method A when X is true") void sampleTestForMethodAWhenX() { System.out.println("Example test for method A when X is true"); } } } }
- The "root" test class contains all test methods of the system under test. Typically I name this class by appending the string:
Test
to a string that identifies the system under test.- An inner class that contains the all tests of a feature or a method. I use the name of the tested feature or method as the name of this inner class.
- The inner classes which which verify that the system under test is working as expected when a specific condition is true. I name these inner classes by prepending the string:
When
to a string that describes the condition. For example, if we are writing tests for a finder method, we could have two inner classes:WhenXIsFound
andWhenXIsNotFound
.
- The inner classes which which verify that the system under test is working as expected when a specific condition is true. I name these inner classes by prepending the string:
- An inner class that contains the all tests of a feature or a method. I use the name of the tested feature or method as the name of this inner class.
Additional Reading:
We have now written a test class that contains nested tests. Let's see what happens when we run our tests.
Running Our Tests
When we run our tests, we should see the following output:
Before all test methods Before each test method Before each test method of the A class Example test for method A After each test method of the A class After each test method Before each test method Before each test method of the A class Before each test method of the WhenX class Example test for method A when X is true After each test method of the WhenX class After each test method of the A class After each test method After all test methods
In other words, JUnit 5 invokes the setup and teardown methods by following the context hierarchy of the invoked test method. This means that we can eliminate duplicate code by putting our code to the correct place.
We have now written a test class that contains nested setup, teardown, and test methods. Also, we understand the invocation order of these methods. Let’s summarize what we learned from this blog post.
Summary
This blog post has taught us five things:
- All nested test classes must be non-static inner classes.
- All nested test classes must be annotated with the
@Nested
annotation. - The depth of the test class hierarchy is not limited in any way.
- A nested test class can contain test methods, one
@BeforeEach
method, and one@AfterEach
method. - By default, we cannot add the
@BeforeAll
and@AfterAll
methods to a nested test class.
P.S. You can get the example application of this blog post from Github.
Nested tests are very useful because our test cases are often not a list, but form a tree. This leads to maintenance issues and duplication when we try to fit that tree in a list of methods annotated with @Test :)
One more thing - I have studied JUnit 5 Guide and totally missed the @TestInstance(Lifecycle.PER_CLASS) as a way to make @BeforeAll/@AfterAll possible on non-static methods. Of course that comes with other limitations, but still - great tip!
You can use non argument constructor in a nested test instead of @BeforeAll
Interesting idea. What are the benefits of using a constructor instead of a setup method?
If I have 2 tests in a nested class, will it run in the same order everytime?
Yes, the JUnit 5 user's manual states that: