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
