Extensibility of Assertion

[andreoss]

Assertion2 is a final class without an interface.
It blocks the user from

• creating custom assertions
• decorating Assertion with additional logic
  And also violates "He Works by Contracts"1 principle of EO.

Examples of use cases:

• conditional assertions, covers the cases of @EnabledIf from Junit 5
• soft assertions, i.e not fail directly but mark test as failed in some kind of storage for later evaluation
• repeated and grouped assertions, covers Assertions.assertAll for Junit 5

Proposal:

• Extract an interface named Affirmation (after the method)
• Discuss which additional implementations which should be brought

[0crat]

@paulodamaso/z please, pay attention to this issue

[andreoss]

@paulodamaso @llorllale Ready to implement if green-lighted.

[llorllale]

@paulodamaso I think the first two use cases make sense:

• conditional assertions, covers the cases of @EnabledIf from Junit 5
• soft assertions, i.e not fail directly but mark test as failed in some kind of storage for later evaluation

WDYT?

[paulodamaso]

@victornoel WDYT?

[victornoel]

@andreoss @llorllale @paulodamaso sorry for the late answer on this :)

Basically, I think it's a good idea to introduce an interface yes. At first I was thinking like @llorllale with his comment about assertAll being the same as AllOf (see #161 (comment)), but I feel like that if we want to have multiple conditional and non-conditional assertions we can't rely on AllOf Matcher for that.

At the same time, I think that if we need multiple assertions, then we should write multiple test methods. Why would we want to group them in one place?

So, I propose to start with a simpler ambition:

• let's introduce the SoftAssertion class
• whose constructor takes multiples Assertion object
• it's affirm method should catch all Exception (or only RuntimeException actually?) and AssertionError for each so that they can all be run
• it should at the end throw a AssertionError with multiple suppressed causes
• of course we need to introduce the Affirmation interface that is documented about what it throws

So, @andreoss @llorllale @paulodamaso @fabriciofx (bringing you in the discussion ;), each of those item of the proposal are open to discussion, what do you think?

[andreoss]

@victornoel

Not sure if directly related to this discussion, but the problem I see with new Assertion(..)affirm() is that one has to call
affirm() method explicitly (which is an easy thing to forget) in each method imperatively.
A more proper way would be to return Assertion. i.e

@TestFactory
Assertion foo() { return new Assertion(...); } 

In order for Assertion to be detectable by Jupiter's @TestFactory it should be implemented like that

public interface Assertion extends Iterable<DynamicNode>  { 
    ... 

    @Override
    default Iterator<DynamicNode> iterator() { ... } 
} 

This sequentially leads to a shorter boiler-plate free form of writing tests (proposed in https://github.com/pragmatic-objects/oo-tests):

final class FooTest extends TestEnvelope { 
    FooTest() {
        super(
            new AssertThat<>(1 + 1, new Is(2)),
            new AssertThat<>(2 + 2, new Is(4))
        );
    }
}

On naming, it seems now that Affirmation is a poor choice, and it would be better to stick with Assertion and keep Assert... as a common prefix.