JUnit 5 Architecture. Part 6
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.
10 Jun 2020
1454
Other articles
How to incrementally migrate the data from RDBMS to Hadoop using Sqoop Incremental Last Modified technique?
How to implement Slowly Changing Dimensions(SCD) Type 2 in Spark?
How to incrementally migrate the data from RDBMS to Hadoop using Sqoop Incremental Append technique?
Why MongoDB don't fetch all the matching documents for the query fired
How to solve the issue of full disk utilization in HDFS Namenode
Can We Use HDFS as Back-up Storage?
How to do Indexing in MongoDB with Elastic Search? Part 1
How to do Indexing in MongoDB with Elastic Search? Part 2
How to store data on browser using NoSQL IndexedDB?
How to Apply MBTI in HR: Motivation for every day. Groups of People & their Motivations
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.
In listing 9, we do the following:
In listing 10, we do the following:
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:
Catalin Tudose
Java and Web Technologies Expert
In listing 9, we do the following:
- We declare CustomExtension as implementing the AfterEachCallback and BeforeEachCallback interfaces (1’).
- We override the afterEach method, to be executed after each test method from the testing class which is extended with CustomExtension (2’).
- We override the beforeEach method, to be executed before each test method from the testing class is extended with CustomExtension (3’).
In listing 10, we do the following:
- We extend JUnit5CustomExtensionTester with the CustomExtension class (1’).
- 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