A detailed look at @Disabled, its conditional counterparts, and how to create custom conditions that allow us to flexibly disable test methods.
The JUnit 5 extension model enables detailed, flexible, and powerful additions to JUnit 5’s core features. For that it provides specific extension points and easy composition of annotations.
Thorough introduction to parameterized tests in JUnit 5: How to create them, how to name them, where to get the arguments from, how to convert then, and how to customize that.
With dynamic tests, JUnit 5 allows us to create tests at run time. With this we can parameterize tests. generate hierarchical test plans, and even define tests with lambdas!
JUnit 4 came in a single artifact, blending all uses cases into one bundle. The JUnit 5 architecture promotes a better separation of concerns and provides clear APIs for testers (Jupiter) and tools (Platform).
Get to know the basics of JUnit 5: @Test, lifecycle methods, assertions, and assumptions; how to disable, name, and tag tests; as well as previews on nesting, parameterization, and test interfaces. Let’s write some tests!
How to set up JUnit 5 so tests run in IntelliJ, Eclipse, Maven, Gradle or, if all else fails, via JUnit 4 or on the command line.
With ‘var’ it is possible to ad-hoc combine traits into an instance that matches your exact requirements. This allows for pretty cool experimentation, but unfortunately has some serious downsides.
Local-variable type inference with `var` makes it easier to work with anonymous classes, for example to create ad-hoc fields and methods. But does that mean you should use them more often? I think not.
With ‘var’ it is much easier to work with intersection types in Java 10 and later. You still need non-trivial tricks with generics to declare intersection types, but thanks to ‘var’ it is now easy to create local variables of such types.