+1 I do think these are generally worthwhile. They are also a great help for consistency. As long as it doesn't require a huge rewrite of the existing codebase I think it's worth while gradually switching.
Russ On Tue, Jun 23, 2026 at 9:03 AM Steve Loughran <[email protected]> wrote: > assertJ is absolutely wonderful and I"d recommend it ...not for > it's assertThatThrownBy but because of > > 1. its assertions on collections, where assertion errors include details > on the collections. e.g assertThat(dataset).isEmpty() will give the > list of > contents of dataset if not empty. > 2. its .describedAs() call takes a string formatter argument for > on-demand creation of error messages if invalid > 3. If you want to do some really advanced stuff you can actually start > writing your own methods to extract and chain values. Esoteric and more > for > people that want to make it easier to assert on new types. > 4. it is stable across junit releases. whereas junit 4 and junit 5 > broke all asserts and even reordered arguments in assertEquals such that > things may compile but not test properly > > w.r.t assertThrows, I personally prefer hadoop's > LambdaTestUtils.intercept() which is a clear rip-off of > ScalaTest.intercept, because it does what the others don't: print the > toString() value of the callable *if the exception isn't raised*. That lets > you write lambdas which return diagnostics info if they don't fail, which > is handy, as it makes its way into test reports. > > public static <T, E extends Throwable> E intercept( > Class<E> clazz, > String contained, > String message, > Callable<T> eval) > throws Exception { > E ex; > try { > T result = eval.call(); > throw new AssertionError(message + ": " + robustToString(result)); > // HERE. > } catch (Throwable e) { > if (!clazz.isAssignableFrom(e.getClass())) { > throw e; > } else { > ex = (E) e; > } > } > GenericTestUtils.assertExceptionContains(contained, ex, message); > return ex; > } > > Despite it's lack of that feature, assertThatThrownBy() is still very good, > and lets you chain things off it. e.g extract the cause and add assertions > on it > > > On Tue, 23 Jun 2026 at 07:55, Eduard Tudenhöfner <[email protected] > > > wrote: > > > Hi everyone, I was wondering what the appetite would be for introducing > > AssertJ <https://assertj.github.io/doc/> to the project? I believe it's > a > > really good testing library that makes writing assertions much more > > intuitive, as the assertions are written in a fluent way. The test code > > ends up being more readable and it provides an actually useful error > > message when assertions fail. > > There are some good examples of how AssertJ is used here > > <https://assertj.github.io/doc/#assertj-core-assertions-guide>, but > > personally what I like most about AssertJ is testing exceptional code > > < > > > https://assertj.github.io/doc/#assertj-core-exception-assertions-assertThatThrownBy > > >, > > where you want to ensure some code throws a particular exception and also > > has message *Xyz* or some other property that you want to assert on. > > No more *@Test(expected = SomeException.class)* or *try-catch* code with > > *Assert.fail()*. > > Also we've been successfully using it in the Apache Iceberg project for > > many years, and it has improved how we write tests. > > I took the liberty of opening PR #3617 > > <https://github.com/apache/parquet-java/pull/3617>, which introduces > > AssertJ to a subset of tests just to show its usage and benefits. > > The idea is to give people a (better) alternative when testing certain > > things, such as collections, exceptions, paths, URIs and so on. People > can > > still use JUnit assertions if they want to, but at least there's an > option > > to use other assertions if needed for cases that are more difficult to > > express/do with JUnit assertions. > > Please let me know what you think Eduard > > >
