+1. AssertJ or Hamcrest provide more helpful error messages. I would not consider it mandatory to use it, but it's a good option to have it. I'm happy that we leave the option to use raw JUnit assertions or AssertJ.
On Mon, 21 Jul 2025 at 16:39, Guillaume Nodet <gno...@apache.org> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
