JUnit 5 Architecture. Part 4
JUnit 5 Architecture. Part 4
The 4th article in our series on JUnit 5 Architecture. We continue our discussions on the Rules vs the extension model and move our attention to the new JUnit 5 approach.
28 трав 2020 1676
Інші статтіHow to debug and solve the issue of Datanodes which were reported as Bad nodes? 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?
Into this JUnit 5 example, we do the following:
- We initialize an instance of the Calculator class whose functionality we’re testing (1’).
- We assert that the execution of the supplied calculator.sqrt(-1) executable throws an IllegalArgumentException (2’).
- 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:
- 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).
- 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.
- 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:
- We declare a @TempDir annotated field (1’).
- We check the creation of this temporary directory before the execution of the test (2’).
- 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:
- We declare our CustomRule class that implements the TestRule interface (1).
- 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.
Java and Web Technologies Expert