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.
[https://i2.wp.com/igorski.co/wp-content/uploads/2018/05/Mockit-Junit-5-1.png] One of the standard Mockito related questions I’ve come across is online is “Can we mock final classes with Mockito?”. The answer to this question since Mockito 2 was introduced is “Yes, we can.”. Example code This
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
When I say “before and after” I refer to running the code always, for all tests, independent whether @Before and @After are present in a test or not. I don’t have in mind simply using @Befores and @Afters. That would mean that you need to add the same before