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 > >
