Enrich assertInstanceOf failure reports with stack trace

[vy]

When assertInstanceOf fails with

org.opentest4j.AssertionFailedError: Unexpected type, expected: <java.net.http.HttpTimeoutException> but was: <java.io.IOException>

my reaction is "Okay, show me the stack trace then.", every single time. I eventually end up replacing assertInstanceOf calls with

if (!(exception instanceof HttpTimeoutException)) {
    throw new AssertionError("was expecting: `HttpTimeoutException`, found: " + exception, exception);
}

Contrast this with AssertJ's assertThatThrownBy(...).isInstanceOf(...) that reports the stack trace of the exception under test in case of an assertion failure. Could we enhance assertInstanceOf to include the stack trace in reports too, please?

Edit: To avoid an XY Problem, let me share my problem as minimal and as isolated as possible:

I want to verify that throw new IOException("foo", new RuntimeException()) throws an IOException whose cause is of type RuntimeException.

What is the most JUnit idiomatic way to do this?

[marcphilipp]

IIUC, you'd like to have actual reported as the cause of the AssertionFailedError, right?

I think that makes sense and would be simple to add:

Subject: [PATCH] Report actual as cause
---
Index: junit-jupiter-api/src/main/java/org/junit/jupiter/api/AssertInstanceOf.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/junit-jupiter-api/src/main/java/org/junit/jupiter/api/AssertInstanceOf.java b/junit-jupiter-api/src/main/java/org/junit/jupiter/api/AssertInstanceOf.java
--- a/junit-jupiter-api/src/main/java/org/junit/jupiter/api/AssertInstanceOf.java	(revision 65e231c4beb339fd54cfef05c51e07213f9c43dd)
+++ b/junit-jupiter-api/src/main/java/org/junit/jupiter/api/AssertInstanceOf.java	(date 1759396665044)
@@ -54,6 +54,7 @@
 					.message(messageOrSupplier) //
 					.reason(actualValue == null ? "Unexpected null value" : "Unexpected type") //
 					.expected(expectedType) //
 					.actual(actualValue == null ? null : actualValue.getClass()) //
+					.cause(actualValue instanceof Throwable t ? t : null) //
 					.buildAndThrow();
 		}

[marcphilipp]

@vy Would you be interested in sending a PR with this change along with a test and release notes entry?

[vy]

@marcphilipp, would be happy to do so. Please allow me some time.

[vy]

@marcphilipp, @sormuras, I've submitted #5041. I'd appreciate your reviews.

[marcphilipp]

Contrast this with AssertJ's assertThatThrownBy(...).isInstanceOf(...) that reports the stack trace of the exception under test in case of an assertion failure.

To be fair, JUnit's assertThrows does that as well.

[sormuras]

So does assertThrowsExactly, just stricter.

[sormuras]

But both variants don't let the user also specify an expected type for the cause throwable.

[vy]

To be fair, JUnit's assertThrows does that as well.

@marcphilipp, though in my case I need to validate against the cause, where JUnit does not help much.
AssertJ's fluent API allows the following:

assertThatThrownBy(() -> { throw new IOException("foo", new RuntimeException()); })
        .isInstanceOf(IOException.class)
        .hasCauseInstanceOf(RuntimeException.class);

I translate this to JUnit as follows:

var ioe = assertThrows(IOException.class, () -> { throw new IOException("foo", new RuntimeException()); });
if (!(ioe.getCause() instanceof RuntimeException)) {
    throw new AssertionError("was expecting a cause of `RuntimeException`", ioe);
}

If assertInstanceOf would report the stack trace, I could instead do this:

var ioe = assertThrows(IOException.class, () -> { throw new IOException("foo", new RuntimeException()); });
assertInstanceOf(RuntimeException.class, ioe.getCause());

This misses the parent exception in the stack trace reported by assertInstanceOf, but that is a caveat I can live with.

[marcphilipp]

though in my case I need to validate against the cause, where JUnit does not help much

Understood. 👍

[vy]

@marcphilipp, @sormuras, I see assertSame can be enhanced in the same manner too. Maybe other assertion methods too? What would you advise?

[sormuras]

So, the question is, should every assertion (and assumption) fill the cause component when the argument(s) are instances of Throwable? Could make sense, as the

Okay, show me the stack trace then."

situation is common and shouldn't need an extra run.

[vy]

@sormuras, agreed.

shouldn't need an extra run

Sadly it is not just a matter of extra run, one needs to change the test code to get the subject Throwable displayed.