satisfiesOnlyOnce stack trace does not point to failed nested assertion

[scordio]

The following:

  @Test
  public void test() {
    Assertions.setRemoveAssertJRelatedElementsFromStackTrace(false);

    List<Integer> list = List.of(1, 2, 3, 4);
    assertThat(list)
        .satisfiesOnlyOnce(
            n -> {
              isFive(n);
            });
  }

  private static void isFive(int n) {
    assertThat(n).isEqualTo(5);
  }

yields:

java.lang.AssertionError: 
Expecting exactly one element of actual:
  [1, 2, 3, 4]
to satisfy the requirements but none did

	at org.assertj.core.error.AssertionErrorCreator.assertionError(AssertionErrorCreator.java:93)
	at org.assertj.core.internal.Failures.failure(Failures.java:126)
	at org.assertj.core.internal.Iterables.assertSatisfiesOnlyOnce(Iterables.java:1241)
	at org.assertj.core.api.AbstractIterableAssert.satisfiesOnlyOnceForProxy(AbstractIterableAssert.java:3998)
	at org.assertj.core.api.AbstractIterableAssert.satisfiesOnlyOnce(AbstractIterableAssert.java:3991)
	at com.github.scordio.junit.playground.AssertJTest.test(AssertJTest.java:93)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

Reported at #2542 (comment) by @upsidedownsmile.

[joel-costigliola]

I'm not too sure what we could improve here, satisfiesOnlyOnce(isFive) succeeds if exactly one element passes isFive. In the given example, it means three isFive assertions fail and one succeeds, it would not make sense to report any isFive failure since they could occur while satisfiesOnlyOnce(isFive) succeeds.

@upsidedownsmile what kind of improvement would you like to see in the error message ?
Could you show us on concrete examples ?

[upsidedownsmile]

Thanks for the explanation @joel-costigliola, now I understand why the underlying assertion error is not in the stackstrace. I forgot that there are different permutations of failed assertions and that's hard to put in the error message.

But right now it is really hard to debug cases where there are several assertions inside a satisfiesOnlyOnce.

A realistic example:
assertSemanticConventionsSpanAttributes has an satisfiesOnlyOnce which will call assertSemanticConventionsAttributes.
In this case it's really hard to understand which assertion failed in assertSemanticConventionsAttributes because the stacktrace only shows line 147.

Is there anything that can be done to improve this?
Maybe we are writing tests the wrong away which causes these debug problem. Let me know if there is a better way to improve debuggability for these cases.

[scordio]

@upsidedownsmile I noticed the links in your message were broken, so I tried to restore them.

I tried to look at the test but I'm not sure I understand how you'd like to verify attributesList.

In case you have a list of requirements and want to make sure that there is exactly one element satisfying it without knowing its position in advance, satisfiesExactlyInAnyOrder might help.