Extract a ComparisonFailure interface from AssertionFailedException

[kcooney]

It would be useful if JUnit4's ComparisonFailure exception could share a common interface with OpenTest4J's AssertionFailedException so 1) IDEs have a simple way to show a diff view on comparison failure and 2) JUnit4 can get better IDE integration for comparison failures for things that are not strings.

This would require some changes to AssertionFailedException, since the JUnit4 ComparisonFailure class already has methods named getActual() and getExpected(). I suggest renaming OpenTest4J's AssertionFailedException methods as follows:

• getActual() -> getActualValue()
• getExpected() -> getExpectedValue()
• isExpectedDefined() -> hasExpectedValue()
• isActualDefined() -> hasActualValue()

The above four methods would be the only methods in this proposed ComparisonFailure interface

[cgruber]

I presume you didn't mean hasisActualValue() but hasActualValue()

[kcooney]

@cgruber fixed. Thanks

[marcphilipp]

We could certainly do this. Another option would be to change Vintage to use AssertionFailedError instead of ComparisonFailure going forward, right?

[kcooney]

@marcphilipp changing JUnit4 in that way would break tests and tools

[marcphilipp]

I don't think it would break a lot of tests and it would only break tools that don't support OTA, right?

[kcooney]

@marcphilipp Eclipse (and probably other IDEs) special case ComparisonFailure. I have seen tests at Goggle that assume that calling certain assertion methods in certain ways result in ComparisonFailure.

While IDEs will eventually be updated to support OTA, it will take time for people to update their IDEs.

What's wrong with extracting an interface as I proposed?

[kcooney]

@marcphilipp any more thoughts on this?

Note that we could change JUnit4's AssertionFailedError extend OpenTest4J's AssertionFailedException, but that would also require renaming the methods as I described in the original bug description.

[marcphilipp]

How would that work in terms of artifact dependencies and JDK compatibility? JUnit4 is still compiled to JDK5 byte code while OTA4J isn't... 🤔

[kcooney]

Sooner or later we will have a release of JUnit4 that is compiled with a more recent JDK (I was originally thinking that we would do that in a point-zero release, but since 5.0 is taken...). We have had a few feature requests that require JDK 6