About #testing

The trap of testing simple orchestration

#testing / Jan 17, 2024 / 6 min
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.
Read the article

Introducing JUnit 5 FormattedSource

#testing / May 3, 2023 / 7 min
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.
Read the article

Pragmatic tests parallelization with JUnit 5

#testing / Nov 24, 2021 / 8 min
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.
Read the article

Parameterize like a pro with JUnit 5 @CsvSource

#testing / Oct 19, 2021 / 6 min
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.
Read the article