Diff.toString() returns only first comparison result

[Boiarshinov]

That's my user story:
I have a test for custom xml marshaller in my work project. Test is written in a way similar to XmlUnit user guide. Last line of my test was:

// JUnit 5 assertion
Assertions.assertFalse(diff.hasDifferences(), diff.toString())

After some test sources refactoring test was failed with message that one of xml tag actual values diffs with expected one.
I fixed the expected value in xml sample and was expecting that test will be green this time.
But it wasn't.
It failed with another message about difference in value of another xml tag.

I found a solution in a assertion refactoring:

Assertions.assertFalse(diff.hasDifferences(), diff.differencies.joinToString("\n"))
// `joinToString()` - is a standard Iterable method in Kotlin

With that refactoring I was able to found all differencies simultaneously and fix them in a one try.

But I think that it would be better to return all failed comparison results in Diff.toString() method.
First of all it's a user guide recommendations to write assertions with toString() invocation.
Also this toString() behavior would match Object.toString() javadoc which says

Returns a string representation of the object.

Only one comparison result cannot be full string representation of the object.

[Boiarshinov]

XmlUnit Enhancement Proposal: #233

[bodewig]

Thank you @Boiarshinov

I don't think changing toString's implementation is the way to go, rather I'd add a new method - which needs to accept a ComparisonFormatter as well. I a way toString's current behavior is a contract provided by XMLUnit that we should not break.

[Boiarshinov]

I separate my initial PR to two new:

• Fix typos #234 - fixing typos
• issue-232: Add method for getting full description from diff #235 - add new method for full description about diff, revert toString() implementation, add javadocs to both toString() methods to fix their contract

I tried to drop commits with cosmetic changes from initial PR and refactor it, but I failed, sorry.

@bodewig What do you think about new fullDescription() method?

[bodewig]

I liked your #235 approached better and merged that. Many thanks.