Spring Boot Starter adds both AssertJ and Hamcrest assertion libraries

[nightswimmings]

I am just wondering whether this makes sense, or it could make more sense to just advocate for a conventional implementation as other Boot defaults, or even make both optional.

Its just confusing with all the assert signatures intermixed in the IDE.
AssertJ seems much more readable and complete, its a single library, more maintained,more suited to autocomplete; it does not have half of the library deprecated and supports nicely latest features of the language, but it's just my opinion.

Has this debate been raised ever?

[wilkinsona]

Thanks for the suggestion. There's nothing that we can do about this at the moment as JUnit 4 depends on Hamcrest. We could remove Hamcrest from the test starter as part of upgrading to JUnit 5, but our goal with that upgrade is to provide people with a seamless upgrade from JUnit 4 (by including the vintage engine). Removing Hamcrest would go against that goal as it would be a breaking change. That said, I've made a note in #14736 so that we can consider this as and when we upgrade to JUnit 5.

[nightswimmings]

Thanks Andy!

[gavvvr]

@wilkinsona there is no jUnit 4 in test starter anymore. Why Hamcrest was left?

I've seen your comment on a chance to remove Hamcrest with the switch to jUnit 5, but did not find any further discussion and decision why Hamcrest was left.

[wilkinsona]

I'm afraid I can't recall why Hamcrest was left in the starter. It may have been an oversight or it may be that there was a good reason for it that I've since forgotten. I'll re-open this one so that we can consider it again.

[philwebb]

Currently Spring Framework's MockMVC classes make use of Hamcrest so I don't think that we should remove it just yet. There's a Spring Framework issue about supporting an AssertJ alternative. I have a feeling there are a few other test libraries that also use it.

I'm going to close this one for now since we can't easily remove it and it's not really hurting things to keep it.