When failing, AssertJ provides more detailed failure message and usually avoid having to debug / modify the test to see what's actually wrong. And while I agree we should try to keep the number of dependencies as low as possible, this point is much more important for runtime than test time.
So +1 for AspectJ. Le lun. 21 juil. 2025 à 08:04, Slawomir Jaranowski <s.jaranow...@gmail.com> a écrit : > > Hi, > > For me AssertJ is more powerful than standard JUnit Assertions. > Assertions with AssertJ are also very good readable for me in code. > > So as it is a test dependency I don't have any problem using it. > Project is very well maintained and has an acceptable license. > > One thing I would like to see is do not mix assertions framework in > one test class - when we use AssertJ use it everywhere in one test > class. > > On Mon, 21 Jul 2025 at 06:51, 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 > > > > -- > Sławomir Jaranowski > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- ------------------------ Guillaume Nodet --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
