'Y'

JUnit 5 Architecture. Part 6

The last article in our series on JUnit 5 Architecture. We now turn our attention to the JUnit 5 approach. JUnit 5 allows similar effects as in the case of the JUnit 4 rules by introducing the own extensions.

The last article in our series on JUnit 5 Architecture. We now turn our attention to the JUnit 5 approach. JUnit 5 allows similar effects as in the case of the JUnit 4 rules by introducing the own extensions. The code is shorter and it relies on the declarative annotations style. We first define the CustomExtension class, which is used as an argument of the @ExtendWith annotation on the tested class. 

The CustomExtension class.JPG


In listing 9, we do the following:
  1. We declare CustomExtension as implementing the AfterEachCallback and BeforeEachCallback interfaces (1’).
  2. We override the afterEach method, to be executed after each test method from the testing class which is extended with CustomExtension (2’).
  3. We override the beforeEach method, to be executed before each test method from the testing class is extended with CustomExtension (3’).

The JUnit5CustomExtensionTester class.JPG


In listing 10, we do the following:

  1. We extend JUnit5CustomExtensionTester with the CustomExtension class (1’).
  2. We create the myCustomRuleTest method and annotate it with @Test (2).

As the test class is extended with the CustomExtension class, the previously defined beforeEach and afterEach methods are executed before and after each test method respectively.

We remark the clear difference in code clarity and code length between JUnit 4 and JUnit 5. The JUnit 4 approach needs to work with three classes, the JUnit 5 approach needs to work with only two classes. The code to be executed before and after each test method is isolated into a dedicated method with a clear name. On the side of the testing class, you only need to annotate it with @ExtendWith.

The JUnit 5 extension model may also be used to gradually replace the runners from JUnit 4. For the extensions which have already been created, the migration process is simple. For example:
  • To migrate the Mockito tests, you need to replace, on the tested class, the annotation @RunWith(MockitoJUnitRunner.class) with the annotation @ExtendWith(MockitoExtension.class).
  • To migrate the Spring tests, you need to replace, on the tested class, the annotation @RunWith(SpringJUnit4ClassRunner.class) with the annotation @ExtendWith(SpringExtension.class).
  • At the time of writing this article, there’s no extension for the Arquillian tests.

Conclusions

The article discussed the the new architecture of JUnit 5 and how it emerged from the shortcomings of the previous JUnit 4 version. We emphasized the he modular approach of JUnit 5. It also showed the migration of the JUnit 4 code to JUnit 5, including here: migrating from rules to extensions; migrating custom rules to custom extensions.

Interested in JUnit? Check out our trainings.


Catalin Tudose
Java and Web Technologies Expert

Share the knowledge

Luxoft Warsaw - Warsaw Spire, plac Europejski 1, 00-844 Warszawa
Dimitrie Pompeiu nr 5-7 , building C, Et. 5, sect 2, Bucharest, 014459

Contact phone:

021 371 4858
Luxoft Poland Wroclaw - Silver Tower pl. Konstytucji 3-go Maja 3 50-048 Wroclaw
Aleja Generała Tadeusza Bora-Komorowskiego 25, Quattro Business Park Five, 31-476 Kraków, Poland

Contact phone:

+48 122110650
Success
Thank you.
Your request has been received.