I just had the same idea this week. I'm writing an XML/HTML formatter, and I have a reasonably large HTML document of what I expect in a unit test. Using a similar approach as TDD, I set up the unit test before the formatter is fully complete, and I need to know which items the formatter needs work on.

Currently I'm placing the expected document and a System.out.prinln() of the formatted output in separate tabs in VS Code and comparing them. This give a nice, colorful diff, but it's all manual.

I don't know if a diff should occur with every use of equalTo(), but maybe that would be OK. Another option would be to add a verbose parameter or a diff parameter. Or maybe even an equalToWithDiff() matcher.

In a perfect world this would also use something like Jansi to provide a color-coded diff, like VS Code, TortoiseGit, and even Eclipse does nowadays.

Hi, I would like to work on this issue @nhojpatrick .
My idea currently is to add Classes/Methods to equalTo matcher family for strings with WithDiff version, e.g. equalToWithDiff as @garretwilson commented. However, I am not sure whether it's okay or not to introduce dependencies to external libraries that provide diff functionality, like Difflib.

I would probably find a heuristic to guess whether the caller would like a diff or not, e.g. something like if the expected string contains more than one \n then show the diff, otherwise don't.

Otherwise we're going to have to go through our millions of assertions and manually change some of them to equalToWithDiff which will take a while.

I think it a great idea to use some heuristics to infer whether to diff the output or not, but It could be difficult to have a general standard. Maybe more discussions are required.