Better assertion' message check

[l3r8yJ]

@volodya-lombrozo I think the description of each assertion should contain placeholders to describe what we actually want to get and what was wrong, otherwise the description message doesn't make any sense, wdyt?

invalid:

@Test
void addsTwoNumbers() {
    int a = 1;
    int b = 1;
    assertThat(
        "1 + 1 is 2",
        sum(a, b)
    ).equalTo(2)
}

valid:

@Test
void addsTwoNumbers() {
    int expected = 2;
    int actual = sum(1, 1)
    assertThat(
        // Can be in any format from String#format up to FormattedText#new
        "1 + 1 should be equal to %s, but was %s".formatted(expected, actual),
        actual
    ).equalTo(expected)
}

[volodya-lombrozo]

"@l3r8yJ, that's a good suggestion actually. I thought about it myself. The check might be rather useful on one hand but require lots of boilerplate code on the other hand. assertThat from Hamcrest and assertEquals from JUnit already print the information if values aren't equal:

@Test
void calculatesSum() {
  Assertions.assertEquals(2, 1 + 1 + 1, "1 + 1 is 2");
}

This gives:

org.opentest4j.AssertionFailedError: 1 + 1 is 2 ==> 
Expected :2
Actual   :3

So, as you can see, there is no need to duplicate expected and actual values twice.

[l3r8yJ]

@volodya-lombrozo sure, good point about boilerplate code, but it seems to be very obvious what happens on simple cases, but in real code unit tests are more complicated. So, even in simple case like this, 2, 1, 1, looks like magic numbers. When we clearly inform what we expecting in test, in my opinion, it's gonna be easier to read.

assertThat from Hamcrest and assertEquals from JUnit already print the information if values aren't equal:

Yes, but in text with placeholders we can put some explanations or additions, what actually was wrong. For example:

"The %s should contain %s.\n\tWhen of %s#methodName was called, this should have modified the original collection, but it didn't happen."
    .formatted(collection, secretElement, caller)

and now, i'm know that i should go to caller and watch what was wrong

Yes, this example very verbose, but, i think it's shows what i'm trying to say, wdyt?

[volodya-lombrozo]

@l3r8yJ I agree with you. Let's start by adding this feature as an experimental one. If it demonstrates promising results, we can then integrate it into our standard list.

[l3r8yJ]

@volodya-lombrozo sure, this feature quite controversial; it would be better if we can switch it back and forth