`satisfies()` with nested assertions obscures stack trace

Summary

satisfies() with nested assertions obscures stack trace

Example

We have a satisfies() call with many embedded assertions like this. AssertJ doesn’t expose the stack trace of the actual line that triggered the assertion in this case, only the satisfies() line:

assertThat( tsdbDeviceMediator.getDeviceSnapshots( 1 ) )
        .singleElement()
        .satisfies( tsdbDevice -> {
            assertThat( tsdbDevice.getRevision() ).isEqualTo( 1 );
            assertThat( tsdbDevice.getPlatform() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getProfile() ).isEqualTo( "ios" );
            assertThat( tsdbDevice.getProfileOverrides() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getModel() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getFirmwareVersion() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getSerialNumber() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.isDynamicIpAddress() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getIpAddress() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getMacAddress() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getSecondaryMacAddress() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getAlias() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getTvModelId() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getDisplayMode() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getSkinResolution() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.getMaxAgeRating() ).isEqualTo( "IOS" );
            assertThat( tsdbDevice.isTombstone() ).isFalse();
        } );

Here’s what it looks like when I run this in IntelliJ. Line 222 is highlighted in the stack trace, but not the actual exception-triggering line:

Interestingly enough, if I wrap this in a try/catch like below and rethrow it as a RuntimeException, it starts working much better:

assertThat( tsdbDeviceMediator.getDeviceSnapshots( 1 ) )
        .singleElement()
        .satisfies( tsdbDevice -> {
            try {
                assertThat( tsdbDevice.getRevision() ).isEqualTo( 1 );
                assertThat( tsdbDevice.getPlatform() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getProfile() ).isEqualTo( "ios" );
                assertThat( tsdbDevice.getProfileOverrides() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getModel() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getFirmwareVersion() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getSerialNumber() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.isDynamicIpAddress() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getIpAddress() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getMacAddress() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getSecondaryMacAddress() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getAlias() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getTvModelId() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getDisplayMode() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getSkinResolution() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.getMaxAgeRating() ).isEqualTo( "IOS" );
                assertThat( tsdbDevice.isTombstone() ).isFalse();
            }
            catch ( Throwable t ) {
                throw new RuntimeException( t );
            }
        } );

Line 227 is properly listed in the stack trace, making it much easier to debug the actual cause of the problem:

Conclusion

Could this be a bug in IntellIJ or AssertJ? 🤔 I tried playing with Assertions.setRemoveAssertJRelatedElementsFromStackTrace(false) but it didn’t seem to affect this.

[joel-costigliola]

we aim to release 3.23.0 at the end of month but in software development there are “sometimes” delays 😄 .

[joel-costigliola]

@perlun I’m closing this issue in favor of https://github.com/assertj/assertj-core/issues/2067 but feel free to continue commenting on it if you feel this is not the best solution.