blog.codeleak.pl

JUnit 4 TemporaryFolder @Rule allowed developers to create tests utilizing temporary directories. With JUnit 5, the @Rule s are not supported hence testing files and directories requireds a little bit of additional work. Fortunately, with JUnit 5.4 there is a new built-in extension to handle temporary directories in tests. And it is extremely easy to use.

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 .

The built-in event publication functionality exists from the early Spring versions and it is still useful for handling basic communication between Spring components in the same application context. In general, the application can generate application events (that can be arbitrary objects) and listen to them. The whole mechanism is really simple: using ApplicationPublisher you publish events and using EventListener you handle them. What I find especially useful is asynchronous and transactional event listeners .

JUnit 5 is the next generation unit testing framework for Java equipped with many interesting features including nested tests, parameterized tests, new extension API or Java 8 support to mentioned a few. This article shows basic concepts of JUnit 5 including test lifecycle, parameter injection and assertions (basic, timeout and exception).

Externalizing Spring Boot application properties is useful when the same application code must be used with different configuration. If the configuration is to be kept away from the source code (which is considered a best practice anyways) spring.config.location environment property can be used to point the directory location with properties files for example. On the other hand, spring.config.name can be used to change the base name of the properties file which defaults to application . The documentation reads: if you don’t like application.properties as the configuration file name you can switch to another . But in what scenario spring.config.name could be used?