CODEWITHSUNDEEP
javaunit-testingjunitjunit4junit5
Fischer Ludrian
Fischer Ludrian

Reputation: 677

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?

Upvotes: 17

Views: 2898

Answers (2)

johanneslink
johanneslink

Reputation: 5341

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.

Upvotes: 19

Eugene
Eugene

Reputation: 120858

This would be required to ask the authors themselves, but it's a common pattern across other libraries.

Guava Preconditions#checkNotNull for example, or even the JDK itself in Objects#requireNoNull. It sort of makes sense for that optional parameter to be the "last one" IMO (but that's opinion based of course).

Upvotes: 0

Related Questions