lambdaisland/deep-diff2

Print string-based diff if there's a mismatch of two strings

or opened this issue · 3 comments

or commented

I sometimes need to write tests for functions that output strings, in particular multi-line strings. Right now deep-diff2 will just say -<expected-string> +<actual-string>, which isn't very useful for longer strings and strings containing newlines.
Right now I try to work around this by splitting the strings on newlines and letting deep-diff2 diff the arrays, which at least will highlight the lines with changes, but it's not great.

I think it'd be useful to print a string-based diff, like git-diff would, if both expressions for a mismatch are string.

For no newlines they could still be printed in place, but for newlines it likely would make sense to introduce a linebreak and then show the diff without worrying about indentation.

I found deep-diff2.printer-impl/print-mismatch, and (and (string? (:- expr)) (string? (:+ expr))) seems like an easy enough condition there, so I'm playing around with it.

Would you consider this for deep-diff2, or do you see problems with the approach? Perhaps it could be an option to not break any existing consumers.

I experimented with something similar: #46. The way the screenshot is displaying it is probably not very readable, however. I think implementing a condition for print-mismatch like you suggest could be a way to make that more readable.

or commented

Ah, cool. I only checked the issues, didn't see there already was a PR. I'm not so sure about an edit difference and the structured representation of the diff.
I've been using a version that displays the diff based on io.github.java-diff-utils/java-diff-utils, so it only works for CLJ.

Making this customizable with a plugin, maybe with a multimethod, might be best to not break any current users and to allow different ways to diff the string.

This is an example of my current implementation:
Screenshot 2023-11-16 at 20 06 48

Marking as "good first issue" since most of legwork has been done and a draft PR #46 exists addressing the issue.