As a rare contributor, I hope I won't be asked to use AssertJ or Hamcrest instead of JUnit assertion APIs (IMO), I find the style unbearable.
Gary On Mon, Jul 21, 2025, 08:02 Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > The thing is that technically it obviously doesn't enable any new use case > but it starts to bring the question of which additional library you want to > support (in terms of code, upgrades, documentations, newcomer learning > curve etc). > JUnit assertions are there and quite do the job well. > Adding assertj means using a new stack or tuning it (first issue) but also > likely being able to justify why you do not use truth which has better > error messages than assertj (was created for that) for example. > So at the end a lot of headache as soon as done for literally 0 gain > (finding it more convenient at coding time is mainly an habit thing). > > I'm not strictly against it (more -0) but a prerequisite to adopt it would > maybe ensure we all agree we should and to migrate all repos at once to > ensure a minimum of consistency otherwise it would just to make happy a few > people and not the community+newcomers IMHO. > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> > | Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > Le lun. 21 juil. 2025 à 13:13, Delany <delany.middle...@gmail.com> a > écrit : > > > If I'm not mistaken Guava's Preconditions is for runtime argument > > validation and should not be used in test code. > > I replaced Hamcrest with AssertJ in my own projects and I don't miss it. > > Its the natural thing to do, and I'll gladly do so for Maven if it means > > supporting AssertJ officially. > > So that leaves JUnit, which is not going anywhere and that's a normal > > situation to have both. > > All technologies start off idiosyncratic. I would argue AssertJ is well > > past that point. > > Delany > > > > On Mon, 21 Jul 2025 at 12:50, Elliotte Rusty Harold <elh...@ibiblio.org> > > wrote: > > > > > Every dependency is a liability, even in test code. I strongly prefer > > > to stick to the standard assertions in JUnit. I also prefer not to > > > have decode idiosyncratic test libraries with slightly varying > > > conventions and arguments. AssertJ is not the only one, not even the > > > only one used in the Maven code base. It seems simple enough if it's > > > all you use, but when you mix it with multiple versions of JUnit, > > > Hamcrest, Guava, and probably others I'm forgetting, it just makes the > > > code harder to read and understand. > > > > > > There are indeed test methods in AssertJ that improve error messages > > > and reporting compared to JUnit. I do wish JUnit had assertContains. > > > However, the casein question wasn't one of these. It was just a > > > different way of writing a standard assertEquals. > > > > > > On Mon, Jul 21, 2025 at 4:53 AM Giovanni van der Schelde > > > <gvdsche...@gmail.com> wrote: > > > > > > > > Hi all, > > > > > > > > In a recent PR review, the use of AssertJ assertions was raised as a > > > point > > > > of discussion. > > > > To avoid recurring debates and ensure the PR is reviewed for the > > changes > > > > it provides, I’d like to propose that we clarify the goal regarding > > this, > > > > and perhaps other, dependencies. > > > > > > > > Specifically, should we: > > > > > > > > - Remove the AssertJ dependency entirely to prevent its use? > > > > - State that we support the dependency and accept its use in our > tests? > > > > > > > > Having a clear stance on this would help streamline code reviews and > > > avoid > > > > repeated discussions on future PRs. > > > > > > > > Perhaps there are already some guidelines on this which I'm unaware > of, > > > so > > > > I'm looking forward to your input. > > > > > > > > Regards, > > > > > > > > Giovanni van der Schelde > > > > > > > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
