hamcrest
`equalTo` matcher should show a diff of the difference to make it possible to see where it is
If large texts are compared with equalTo, you just get both texts in full, and ultimately have to copy them out to text files manually and run a diff tool to figure out what the difference is. This is made worse because downstream tools reading the results don't produce diffs themselves. (To point the finger at one of the major suspects, IntelliJ IDEA shows diffs but only for tiny strings, even though for tiny strings you don't really need a diff to see the difference, but then doesn't show it for large strings, where you certainly can't see the difference without using diff.)
I think it's reasonable for the matcher's description of the mismatch to include this sort of thing as the primary message, and maybe include the full messages only for further information.
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.