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
>
