1. Home
2. Blog
3. JUnit 5 Architecture. Part 3

 

6. Rules vs the extension model

 

In order to put face-to-face the rules model of JUnit 4 and the extension model of JUnit 5, let’s use a Calculator class (listing 1). It’s used to execute mathematical operations, from verifying their systems under test. We are interested in testing the methods that may throw exceptions. One rule is ExpectedException. It can be easily replaced by the JUnit 5 assertThrows method.

 

 

The logic that may throw exceptions into the Calculator class does the following:

1. Declares a method to calculate the square root of a number (1). In case the number is negative, an exception containing a particular message is created and thrown (2).
2. Declares a method to divide two numbers (3). In case the second number is zero, an exception containing a particular message is created and thrown (4).

 

Listing 2 provides an example that specifies which exception message is expected during the execution of the test code using the new functionality of the Calculator class above.

 

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

1. We declare an ExpectedException field annotated with @Rule. The @Rule annotation must be applied either on a public non-static field or on a public non-static method (1). The ExpectedException.none() factory method creates an unconfigured ExpectedException.
2. We initialize an instance of the Calculator class whose functionality we’re testing (2).
3. The ExpectedException is configured to keep the type of exception (3) and the message (4), before being thrown by invoking the sqrt method at line (5).
4. The ExpectedException is configured to keep the type of exception (6) and the message (7), before being thrown by invoking the divide method at line (8).

Tudose, Florin-Catalin Tudose

Java Champion; Java Chapter Lead; Author at Pluralsight and Manning