Introduce `assertSize()` in Jupiter assertions

[chia7712]

Sometimes, we want to assert the size of collection/map, and we want to show the content of collection/map if it fails. For example:

assertEquals(3, collection.size(), "actual: " + collection);

or

assertEquals(Collections.emptyList(), collection);

It would be nice if we can have a sugar assert to simplify above code. For example:

assertSize(0, collection);
assertSize(3, collection);

or

assertIterableEquals(3, collection);
assertIterableEquals(3, map.entrySet());

[sormuras]

What would be an upper limit of shown elements? 3, 10, 99, ...?

[chia7712]

What would be an upper limit of shown elements? 3, 10, 99, ...?

That is a good question. I don't think about it before, as we avoid testing such big collection :smile:

Maybe it has a default value 10 and has a assert which can accept custom limit?

[sormuras]

Did you give AssertJ .hasSize(...) a shot? https://www.javadoc.io/doc/org.assertj/assertj-core/latest/search.html?q=hasSize

// collection specific assertions (there are plenty more)
// in the examples below fellowshipOfTheRing is a List<TolkienCharacter>
assertThat(fellowshipOfTheRing).hasSize(9)
                               .contains(frodo, sam)
                               .doesNotContain(sauron);

As we state in the User Guide about Third-party Assertion Libraries:

Even though the assertion facilities provided by JUnit Jupiter are sufficient for many testing scenarios, there are times when more power and additional functionality such as matchers are desired or required. In such cases, the JUnit team recommends the use of third-party assertion libraries such as AssertJ, Hamcrest, Truth, etc. Developers are therefore free to use the assertion library of their choice.

[chia7712]

Did you give AssertJ .hasSize(...) a shot?

yep, that is good suggestion! We do consider using AssertJ instead. However, it needs huge migration (maybe it can be addressed by OpenRewrite) and it will cause many conflicts between branches. That is why I try to raise a issue (wish?) first to keep using Junit.

I will close this issue if junit team do recommend to use third-party library instead of introducing new assert :)

[scordio]

We do consider using AssertJ instead. However, it needs huge migration (maybe it can be addressed by OpenRewrite)

We documented some migration options at https://assertj.github.io/doc/#assertj-migration and feel free to let us know if you face problems 🙂

[chia7712]

We documented some migration options at https://assertj.github.io/doc/#assertj-migration and feel free to let us know if you face problems 🙂

Thanks for sharing! The docs is great and I have gave a try. Everything is good. The main concern is about code conflicts between branches. We don't backport such changes, so replacing the assertion tools can cause huge difference between branches and it could obstruct us from backporting bug-fix/feature in the future. Hence, adding a new assert to junit 5 is more acceptable to us :smile:

[sbrannen]

Thanks for the proposal, @chia7712.

I will close this issue if junit team do recommend to use third-party library instead of introducing new assert :)

Yes, that's our recommendation.

In light of https://github.com/junit-team/junit5/issues/3854#issuecomment-2159945529 and https://github.com/junit-team/junit5/issues/3854#issuecomment-2160035943, I am closing this issue.

Cheers