Search code examples
javaunit-testingjunitjunit4junit5

Why was the optional assertion message in assertEquals moved to the last position in Junit 5?


In JUnit 4, the optional assertion message was the first parameter in the assertEquals method. In JUnit 5, it's the last.

Is there any technical reason why it was moved to the last position? And if so, which?


Solution

  • I'll try to clarify our thought process when designing the JUnit 5 API (now manifested in the Jupiter test engine) 3 years ago. The others who were present at the time (Marc Philipp, Sam Brannen, Matthias Merdes and Stefan Bechtold) may chime in and correct my memories...

    We had a few basic constraints:

    1. The JUnit 5 API should - from a compiler's perspective - be completely separate from older versions, so that tests from different versions could stand side by side

    2. Nevertheless, the API should feel familiar in order to make migration easy

    3. The API should incorporate state of the art and good practices of Java API design

    Deciding that the optional message argument of all assertion methods in org.junit.jupiter.api.Assertions will always be last was a trade-off between points 2 and 3. This made even more sense as we allowed Supplier<String> messageSupplier arguments. Using lambda expressions in the first position of an assertion statement would look strange and distracting - so we thought.

    Judging from hindsight I'd probably argue for a more radical change of the assertion API in order to forgo confusions of the kind touched in this question. I'd even push for not using @Test as the primary marker for test methods considering how often JUnit Jupiter newcomers import the old org.junit.Test annotation and wonder why the system is behaving strangely.