Here's practical JUnit 5 guide.
I am writing this guide for someone who already knows Java and wants to quickly learn JUnit 5 to start writing testcases.
By default, JUnit 5 pass tests unless explicitly failed.
This behaviour is opposite of JUnit 4, where test was considered failed unless explicitly passed.
Notice method do not have public
in JUnit 5. This is recommended approach to write JUnit Tests.
Methods require @Test
annotation to denote that they are testing methods.
Methods should have this format
Given
When
Then
Method names should reflect intention of Test method. Eg. should_return_true_when_evenNumberPassed()
Method should not have any access modifier. Unlike JUnit4, in JUnit 5, it is recommended to avoid it unless you explicitly need to add modifier.
Ideally, your unit tests should cover all scenarios including edge cases. You can write multiple test methods to cover each scenario. In fact, its good idea to write separate test method to cover separate scenarios.
Assertions are a way to enforce specific conditions for test to pass or fail. In simple terms, it is way to check certain things so that we can descide test should pass or fail.
Following are some of important assertions that you may encounter.
Suppose we are writing a method which returns true for even number and returns false for odd number, our method can be tested with boolean assertions of JUnit 5.
Notice that we are writing 2 separate tests to check 2 different scenarios. Such a test would inform us if isEven
method malfunctions.
In method under test, we are returning null if either input array is empty or null.
This serves as good method to write null assertion tests.
If we ever get NullPointerException
in our code, its good idea to write a null check test for specific scenario.
In method under test, we are performing simple addition based on 2 integers passed to method.
In first test method, we are checking for correct result from method.
Note that we need not check just integers with AssertEquals
, this method is capable of testing any other type of data including String values.
In second test, we are checking for assert not equals. This may not be idealistic test in real world as their are lot more scenarios possible for such a test. But for demonstration, this serves good example. It is just to show you that such an assertion is possible.
Ideally, you may want to test arrays in AssertEquals style ie match values in two different arrays.
However, in this case, AssertEquals do not work as arrays are references in Java and assert equals checks for reference values(address of memory) and calls it failed test.
So to check values of array and not their reference values, we can use AssertArrayEquals. Also it checks for different combinations of items in array.
In method under test, we are throwing ArithmeticException
if y is passed 0.
If we try to check for exceptions with method call to method under test, it will stop execution as JVM will encounter exception while processing method.
To avoid JVM from stopping execution, we nest code for method call in lambda function and catch object in special object of type Executable.
This Executable instance can be checked for respective exception.
However, note that you should be aware of Exception heirarchy as assertions to parent exceptions will also result in test passing.
Similar to assertThrows, we can assertDoesNotThrow exception. This is good way to ensure we do not throw any runtime exception for our case.