Each unit test method should perform exactly one assertion

There are two reasons to aim for each unit test to have exactly one assertion:

When a unit test fails, it is much easier to determine what went wrong. If a failed unit test has three assertions, further effort is required to determine which one failed. If a failed unit test has only one assertion, no such effort is required.

When a unit test performs more than one assertion, it is not guaranteed that all of the assertions occur. In particular, if an unchecked exception occurs, the assertions after the exception do not happen; instead, JUnit marks the unit test method as having an error and proceeds to the next test method. Therefore, strive for one assertion per test method.

Use the most appropriate assertion methods

JUnit has many assertion methods - assertEquals, assertTrue, assertFalse, assertNull, assertNotNull, assertArrayEquals, assertSame. Know the assertions in the latest version of JUnit and use the most appropriate one to have the most readable test code.

Create unit tests that target exceptions

If some of your test cases, which expect the exceptions to be thrown from an application, use “expected” attribute like this. try avoiding catching exception in catch block and using fail/ or asset method to conclude the test.

JUnit 5 Repeated Tests

Aggregating Tests in Suites

JUnit framework provides facility to run multiple Test Classes at a time using Suite as a runner. We can combine the test classes by a feature of modules and run respective Test Classes using Suite Runner.

Migrate from JUnit 4 to JUnit 5

I believe that maintaining libraries up-to-date is very important.

The advantage of JUnit 5 over JUnit 4

The entire JUnit 4 framework was contained in a single jar library. The whole library needs to be imported even when only a particular feature is required. In JUnit 5, we get more granularity and can import only what is necessary

One test runner can only execute tests in JUnit 4 at a time (e.g. SpringJUnit4ClassRunner or Parameterized ). JUnit 5 allows multiple runners to work simultaneously

JUnit 4 never advanced beyond Java 7, missing out on a lot of features from Java 8. JUnit 5 makes good use of Java 8 features The idea behind JUnit 5 was to completely rewrite JUnit 4 to solve most of these drawbacks