ValidationMessage.toString should contain all properties used for equality check

[koppor]

I am unit testing validation.

        Arguments.of(
            Collections.singleton(
                (new ValidationMessage.Builder())
                    .type("pattern")
                    .code("1023")
                    .path("$")
                    .arguments("___version")
                    .format(
                        new MessageFormat(
                            "{0}.{1}: does not match the regex pattern ^1\\.0\\.(0|[1-9]\\d*)(?:-((?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\\.(?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\\+([0-9a-zA-Z-]+(?:\\.[0-9a-zA-Z-]+)*))?$"))
                    .build()),
            Paths.get(
                "wrong-version.json")),

The test fails:

org.opentest4j.AssertionFailedError: expected: java.util.Collections$SingletonSet@6f2cb653<[$._version: does not match the regex pattern ^1\.0\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$]> but was: java.util.LinkedHashSet@14c01636<[$._version: does not match the regex pattern ^1\.0\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$]>
Expected :[$._version: does not match the regex pattern ^1\.0\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$]
Actual   :[$._version: does not match the regex pattern ^1\.0\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$]

In IntelliJ, I can "Click to see the difference":

How can I quickly find out the differences without debugging?

Thus, I propose to include all properties in toString which are used at equals.

[stevehu]

We have a pending issue with the error messages. It is still in active discussion but we are leaning to the specification recommendations.

#286

[koppor]

In case the ValidationMessage is changed to something containing more than the specification demands, there should be toString() and getMessage() (or toReadbleString())

[stevehu]

@koppor I think these methods all have their purposes.

[koppor]

@stevehu Yeah, I think, the purposes are different. toString() is IMHO for debuggin (also backed by the article at https://dev.to/kylec32/effective-java-tuesday-override-tostring-14n7). Maybe you like Lombok's @ToString?

[stevehu]

I agree with you that toString is used mostly internally like debugging or auditing. Lombok's toString generator looks pretty good; however, I don't think we should introduce another library for this purpose. In my opinion, we want to ensure that this library is as green as possible to not introduce any dependency conflict to users. We basically follow the same principle for the entire light platform.