Into this JUnit 5 example, we do the following:

1. We initialize an instance of the Calculator class whose functionality we’re testing (1’).
2. We assert that the execution of the supplied calculator.sqrt(-1) executable throws an IllegalArgumentException (2’).
3. We assert that the execution of the supplied calculator.divide(1, 0) executable throws an ArithmeticException (3’).

We remark the clear difference in code clarity and code length between JUnit 4 and JUnit 5. The effective testing JUnit 5 code is 13 lines, the effective JUnit 4 code is twenty lines. We don’t need to initialize and manage any additional rule. The testing JUnit 5 methods contain one line each.

Another rule we would like to migrate is TemporaryFolder. The TemporaryFolder rule allows the creation of files and folders that should be deleted when the test method finishes (whether it passes or fails). The JUnit 4 rule has been replaced with the @TempDir annotation in JUnit 5. Listing 4 presents the JUnit 4 approach.

Into this example, we do the following:

1. We declare a TemporaryFolder field annotated with @Rule and initialize it. The @Rule annotation must be applied either on a public field or on a public method (1).
2. We use the TemporaryFolder field to create a folder and a file (2). These ones are to be found into the Temp folder of your user profile into the operating system.
3. We check the existence of the temporary folder and of the temporary file (3).

Now, we move our attention to the new JUnit 5 approach (listing 5).

Into the previous JUnit 5 example, we do the following:

1. We declare a @TempDir annotated field (1’).
2. We check the creation of this temporary directory before the execution of the test (2’).
3. We create a file within this directory and check its existence (3’).

The advantage of the JUnit 5 extension approach is that we don’t have to create the folder by ourselves through a constructor, but the folder is automatically created once we annotate a field with @TempDir.

We move our attention to replacing a custom rule. Own rules are particularly useful when some types of tests need similar additional actions before and after their execution.

In JUnit 4, we needed our additional own actions to be executed before and after the execution of a test. Consequently, we may create our own classes which implement the TestRule interface. To do this, one has to override the apply(Statement, Description) method which returns an instance of Statement. Such an object represents the tests within the JUnit runtime and Statement#evaluate()runs them. The Description object describes the individual test. We can use it to read information about the test through reflection.

To clearly show how to define our own rules, we look at listing 6, where we do the following:

1. We declare our CustomRule class that implements the TestRule interface (1).
2. We keep references to a Statement field and to a Description field (2) and we use them into the apply method that returns a CustomStatement (3).

Interested in Java? Check out our trainings.

Catalin Tudose
Java and Web Technologies Expert