Adopt some asserts from assertj

[jimshowalter]

We don't use assertj because developers can forget to finish assertions (and their documentation even says as much: https://assertj.github.io/doc/#forgetting-to-call-an-assertion, and then says to work around that with static-analysis tools, which aren't needed with JUnit assertions).

However, there are some asserts in assertj that are really useful, for example isEqualToComparingFieldByFieldRecursively, which puts us in a bind. We wind up having to write rules that allow only certain uses of assertj, instead of just being able to Gradle exclude it entirely.

You could review the available assertj asserts and, for everything that requires extra work to achieve the same result in JUnit, add similar functionality to JUnit.

[scordio]

My two-biased-cents:

We don't use assertj because developers can forget to finish assertions

This is a general issue for any library that leverages fluent API. Certain IDEs like IntelliJ IDEA might help as they perform static analysis and immediately display unfinished assertions.

You could review the available assertj asserts

Since AssertJ is an assertion-focused library, what you get is vastly bigger than what JUnit offers today: bringing the same features into JUnit can be quite an effort.

[sbrannen]

As stated several times in this issue tracker as well as in the User Guide, the JUnit team does not aim to compete with 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.

In light of that, I am closing this issue.

[jimshowalter]

@scordio, there's a big difference between a fluent builder, which has an outcome the compiler can check (as in, forget to call build() and no object is assigned), and a fluent assertion that a developer can forget to complete, and that needs an additional tool to check (and that assumes the developer remembers to configure the additional tool).

@sbrannen we had read your documentation and had seen that paragraph. We were simply asking you to reconsider.