Orchestration code organizes calls to other components (dependencies) into a certain process. Such pieces of code are sometimes called coordinators or controllers. Orchestration code is usually simple. There’s no (or almost no) conditional logic, or algorithmic complexity. Its main job is to delegate the work to appropriate dependencies in a specific order. Separating orchestration from the actual “heavy” work is a good thing. This way they can be tested independently. Theresulting code units are smaller and thus more testable. Yet, orchestration code itself rarely benefits from unit testing.
Quite some time ago, JUnit’s @CsvAnnotation caught my attention. It turned out so interesting, that I dedicated it a separate blog post and a significant part of a conference talk. It also inspired me to create a new way of writing parameterized tests with JUnit 5.
The JUnit 5 FormattedSource library allows defining test case arguments in a human-readable way, following a user-defined format. As a result, it can be used to improve tests readability. Let’s have a look at an example:
Running tests sequentially seems to be the current status quo in the Java community, despite the number of CPU cores our computers have these days. On the other hand, executing all of them in parallel may look great on paper, but it’s often easier said than done, especially in the already existing projects.
With version 5.3, the JUnit framework has introduced experimental support for the parallel test execution, which can allow selective test parallelization driven by the code. Instead of an exhaustive overview of this feature (the official User Guide does a great job here), I’d like to propose a pragmatic solution, that should be applicable to many types of projects. You can think of it as a low-hanging fruit of test parallelization.
Parameterized tests are definitely my favorite feature of JUnit 5. Defining multiple sets of arguments for the same test can significantly reduce the amount of the test code. Recent additions to the JUnit 5 enable us to write such tests in a whole different way, improving both readability and expressiveness.
This article won’t be yet another primer/overview (like this great introduction from @nipafx). Instead, I’d like to show some not-so-obvious ways of defining test inputs in an elegant, tabular way with JUnit 5. Probably, the fans of the Spock framework (and its Data Tables) would already have an idea of how it could look like, but it’s a non-goal to compare these two frameworks here.