blog.codeleak.pl

JUnit 5 brings a lot of improvements in the assertions library, mainly thanks to Java 8 and Lambda Expression support and thanks to the presence of the new assertions like assertAll , assertTimeout or assertThrows . Although I really like JUnit 5 I believe that AssertJ is still a must in production grade unit tests and I will continue using it. But I think there are potential scenarios of mixing both JUnit 5 and AssertJ in single unit test: one of them is mixing JUnit assertAll with AssertJ assertThat .

One of the rules of writing good unit test is that it should fail for one reason, so unit test should test one logical concept. Sometime it is quite tough to have a single assertion per test. To follow the rule, we may have having multiple assertions per object in a single test. The problem with multiple assertions in a single test though, is that if the first one fails for any reason we actually don’t know about other assertions as they will not be executed. And you know the drill: you check assertion failure reason, you fix it and re-run the test. Maybe you are lucky and the test will pass. But maybe it will fail with another assertion. With really fast unit tests this is not a big issue but when it comes to, for example, Selenium tests analysis and failure detection can become cumbersome and for sure time consuming. Fortunately, we can re-think the way we create assertions in our tests thanks to AssertJ’s SoftAssertions .

AssertJ 3.0.0 release for Java 8 makes testing exceptions much easier than before. In one of my previous blog post I described how to utilize plain Java 8 to achieve this, but with AssertJ 3.0.0 much of the code I created may be removed. Warning: this blog post contains mostly the code examples.

Inspired by the @tkaczanowski talk during GeeCON conference I decided to have a closer look at custom assertions with AssertJ library.