A detailed look at @Disabled, its conditional counterparts, and how to create custom conditions that allow us to flexibly disable test methods.
JUnit 5 is the next version of Java’s most ubiquitous testing framework.
Its incremental improvements and extensible design make it a worthy successor of the battle-tested JUnit 4. But its secret power is its thoughtful architecture, which may very well redefine the future of testing on the JVM.
A series of posts covers all the details – obvious and hidden ones – of JUnit 5. If you want to learn more about the topic, you can hire me as a trainer.
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.
JUnit Lambda will eventually bring us JUnit 5. This is a discussion of the recent prototype, its features, core principles and compatibility considerations.