Hi, Generally and while I agree the features look good, I tend to avoid it in project in favor of a proper custom message supplier with standard junit assertions to avoid to have multiple choices in the project and byte-buddy dependency without playing with exclusions and loose silently features (always harder for newcomers to identify).
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 à 08:39, Guillaume Nodet <gno...@apache.org> a écrit : > 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 > >
