Explore JUnit5's test ordering feature: a blessing for integration tests in microservices. Take a glance at its strengths, use cases, and potential pitfalls.
Test names usually tend to become very long and difficult to read. JUnit5 allows us to set custom test display names, different from the test method names.
Testing for exceptions in JUnit has never been a very straightforward thing. I've often seen it mangled, misused or not well executed, especially in JUnit 4.
Before JUnit 5 running tests in parallel was not easy. Luckily, now we have JUnit 5, and it has the possibility of running tests in parallel out of the box.
Although not a novelty concept, dynamic tests in the current form were introduced in JUnit 5. The main point of dynamic tests is to demonstrate that users can can generate tests dynamically, at runtime.
One issue that I ran into when generating JaCoCo reports is that I would get different reports for each of my test tasks. What I needed was to join the reports and get a single report for the overall test coverage of my code.
JaCoCo is one the most used tools for generating coverage reports for JUnit tests. One of the reasons for it being so used is it's seamless integration with tools like Jenkins, SonarQube, Maven and Gradle.
With Gradle, very little comes out of the box and a lot of the filtering and configuration you need to do on your own. That can be confusing at first especially as a beginner and even more so if you are accustomed to Maven.
I was contacted recently by the guys over at Samebug [https://samebug.io]. We had a few chats about their product and we came to the subject of JUnit5 extensions. At that point, I volunteered to make a Samebug extension, one that will harness Samebug’s power and enrich the
Thanks to the new architecture that JUnit 5 introduces it is possible to run both JUnit 4 and JUnit 5 tests in the same project.
Since version2.16.3 [https://github.com/mockito/mockito/pull/1221]Mockito has official support for Junit5. Using Mockito with JUnit now is even easier than before. Previously I kept forgetting what rule I was supposed to use for injecting the mocks, and how I set the strictness again? Plus
JUnit 4 extension model is a bit scary. You have @Rule, @ClassRule, and different Runner implementations. Very often you need to use all of them at once. On top of that you will probably end up with multiple rules that you will need to chain properly. Doable, but scary for