AssertionFailedError on strings comparison doesn't report diff precisely

[olcariz]

I recently upgraded to Junit 5, which uses in turn openAssert4j and AssertionFailedError on comparison failures.

It seems that, on strings comparison at least, opentest4j doesn't locate the diff content and just settle to report the whole string.

With AssertionFailedError (whole string in expected and actual) :

org.opentest4j.AssertionFailedError: expected: <A simple phrase. A second phrase. A third phrase.> but was: <A simple phrase with a modification. A second phrase. A third phrase.>

With Junit4 and the embedded ComparisonFailure (diff located):

org.junit.ComparisonFailure: expected:<A simple phrase[]. A second phrase. A...> but was:<A simple phrase[ with a modification]. A second phrase. A...>

I do not know if this is a bug or non-implemented feature, but with large string comparison, the lack of this feature begins to be annoying.

Regards, Olivier

[marcphilipp]

I think we originally left off this feature as IDEs show a rich diff for you anyway. But when looking at failures via a build tool I agree that it would be helpful.

@oliviercarizzoni Would you be interested in submitting a PR?

[jccampanero]

@marcphilipp Is the issue still open? Please, would you mind if I work on it?

As far I understand, the requirement is trying providing an output similar to the one provided by ComparisonFailure in JUnit 4. Can we reuse the same class, is it advisable? Can we search for any diff view library - for instance, diff-patch-match, which is Apache 2.0 License as well, with a convenient formatting? Must we implement our own?

Thank you very much.

[marcphilipp]

@jccampanero Yes, the problem is still unsolved. However, we've recently added support for passing FileInfo as expected/actual values which will probably complicate things here.

In any case, I just noticed #39 has more info on this so I'm closing this issue as a duplicate.

[marcphilipp]

Duplicate of #39

[jccampanero]

Thank you very much @marcphilipp Marc, I understand.

Can I help you in any way with #39?

[marcphilipp]

Sure, I think a good next step would be to look at existing implementations (e.g. in JUnit 4 and Spock) and propose what should be changed in #39.

[jccampanero]

Sorry for the late reply @marcphilipp.

Thank you very much for the advice: yes, of course; I will try working on it.