How to reuse AssertJ assertions on custom assertions?

[xtaixe]

The examples on the custom assertions docs implement the assertion logic directly, but for more complex checks it would be nice to reuse the assertions that AssertJ already provides and I'm not sure how to that properly.

First of all, I'm not sure if classes in the internal package (e.g. Iterables.instance() or Strings.instance()) are intended to use outside AssertJ and could help somehow.

Other than that after looking around I think something like this should be done to respect the error, description, etc. if set by the user:

public S customComplexAssertionForInternalProperty() {
    var assertion = assertThat(property)
            .withFailMessage("Default message")
            .withRepresentation(getWritableAssertionInfo().representation())
            .describedAs(getWritableAssertionInfo().description());

    if (getWritableAssertionInfo().overridingErrorMessage() != null) {
        assertion.withFailMessage(getWritableAssertionInfo().overridingErrorMessage())
    }

    assertion.complexAssertion()
    return myself;
}

I also looked into the withAssertionState method, but although it partly fits the bill and would fill even more information depending on the assertion class, it's currently package private and there would still be the need to check somehow if the user set their own values or appropriate defaults should be used (e.g. "Default message" vs getWritableAssertionInfo().overridingErrorMessage() above).

Would it be possible to add something to more easily support this? Or is there already a recommended way or reusing assertions that could be documented? Any guidance will be appreciated.

Thanks.

[scordio]

for more complex checks it would be nice to reuse the assertions that AssertJ already provides

Assuming you are creating a custom assertion class, you might want to extend AbstractAssert or AbstractObjectAssert:

• AbstractAssert exposes a smaller API surface and you would have full control over the assertion methods you'd like to add on top of the common ones (isEqualTo, isInstanceOf, isNull, etc.).
• AbstractObjectAssert offers some additional methods out of the box that might be handy for asserting instance properties (extracting, returns, doesNotReturn)

I'm not sure if classes in the internal package (e.g. Iterables.instance() or Strings.instance()) are intended to use outside AssertJ and could help somehow.

They're not intended to be used outside AssertJ and you would get a failure in both JPMS and OSGi world if you try to do that.

Could you provide some more context on what you're trying to achieve? Would you have the chance to sketch the custom assertion you are trying to design in a GitHub project, together with the type you are targeting?

[obfischer]

Hi @xtaixe, hi @scordio,

I have the same problem as @xtaixe and after reading all your comments, wouldn't it be helpful to provide a small example project at GitHub?

BTW, reusing existing assertions easily and have the same result quality as with native AssertJ assertions is not easy. I think this is the reason why so less of us write domain specific assertions, although this would improve the readabilty of tests.

[joel-costigliola]

I would be helpful to provide such a project so that we can experiment with it and confirm that what we will be doing goes in the right direction. I see these improvements for AssertJ 4 since we will likely have to break backward compatibility (hopefully not too much)

[obfischer]

The repo is available at https://github.com/obfischer/private-assertj-reusing-native-assertions, but contains currently a very small issue.

@xtaixe Would you like to contribute?

[xtaixe]

I will try to find the time. Meanwhile, @joel-costigliola please consider the examples and issues provided in this discussion and I guess a summary would be:

• Be able to create custom assertions for complex/aggregator types by reusing/composing existing ones for the types of its fields.
• Still be able to chain assertions (asserThat(complexType).isSomething().isSomethingElse().satisfiesWhatever()).
• Be able to provide specific "configuration" for the reused assertions (e.g. different failure message) that only applies if the user didn't provide their own.

Happy to answer any questions.

[obfischer]

Hi @scordio,

having a more extensive documentation on this topic would be very helpful. Im my last project I tried to provide some custom assertions for our domain objects. I had to dig through the existing code base and had to experiment several approaches, especially then working with lists and switching to (sub-) domain objects and so an.