Trim internal frames from AssertionFailedError

[mpkorstanje]

When using JUnit.start and creating a failing test, users will be confronted with a large stacktrace with mostly irrelevant information. Even after #5158 is merged, the stacktrace will contain several internal frames:

org.opentest4j.AssertionFailedError: expected: <11> but was: <12>
	at org.junit.jupiter.api@6.1.0-SNAPSHOT/org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:158)
	at org.junit.jupiter.api@6.1.0-SNAPSHOT/org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:139)
	at org.junit.jupiter.api@6.1.0-SNAPSHOT/org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:201)
	at org.junit.jupiter.api@6.1.0-SNAPSHOT/org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:152)
	at org.junit.jupiter.api@6.1.0-SNAPSHOT/org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:147)
	at org.junit.jupiter.api@6.1.0-SNAPSHOT/org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:558)
	at com.examp.project/com.example.project.HelloTest.stringLength(HelloTest.java:14)

By pruning these internal frames, the stacktrace can be reduced to a much more readable:

org.opentest4j.AssertionFailedError: expected: <11> but was: <12>
	at com.examp.project/com.example.project.HelloTest.stringLength(HelloTest.java:14)

Comparable behaviour can be found in AssertJ[1] and IDEA which folds internal frames in the console using <6 internal lines>.

The pruning functionality is intentionally added to the AssertionFailureBuilder rather than the ExceptionUtils to enable other users to also prune the internal frames from their own assertions.

1. https://github.com/assertj/assertj/blob/79bdebf1817692e5e0ff5ee3ab097dcd104d47ae/assertj-core/src/main/java/org/assertj/core/util/Throwables.java#L117-L148

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[mpkorstanje]

Should assumptions also be trimmed?

[marcphilipp]

I think we should preserve the bottomost Assertions/Assumptions stack frame:

org.opentest4j.AssertionFailedError: expected: <11> but was: <12>
	at org.junit.jupiter.api@6.1.0-SNAPSHOT/org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:558)
	at com.examp.project/com.example.project.HelloTest.stringLength(HelloTest.java:14)

[mpkorstanje]

I'm not convinced that this extra frame is useful. Users will never visit it, because the frame above it is their code and the place they'll ultimately have to fix the issue.

public class HelloTest {

    @Test
    void stringLengthJupiter() {
        org.junit.jupiter.api.Assertions.assertEquals(11, "Hello JUnit2".length());
    }
    @Test
    void stringLengthAssertJ() {
        org.assertj.core.api.Assertions.assertThat("Hello JUnit2".length()).isEqualTo(11);
    }
}

And looking at other projects: IDEA already filters it out. And AssertJ doesn't include it in the first place. edit: As does Google Truth.

On a more technical note, for the exceptions thrown by the infline fun in Assertions.kt the stack frames must either start at AssertionFailureBuilder.build or the test method. In which case the latter seems preferable.

What benefits do you think this extra frame adds?