Coverage remained the same at 91.793% when pulling 50ff600 on Boiarshinov:issue-252_tests_fails_on_windows into 0a61c82 on xmlunit:main.

Wow, it's seems that Java 7 not support \R in regular expressions. I will try to fix regex and update PR

I changend \R to (\r\n?|\n) for assertj module and saved \R for assertj3 module because it's always run on Java 8.
Now all works correctly both on Windows + Java 8 and Linux + Java 7+.

thanks a lot @Boiarshinov !

Is it necessary to replace the %n sequence in expectAssertionError? Doesn't the format string help with the platform sensitivity? I'm really just asking here as I must admit I haven't tried to build XMLUnit on Windows for quite some time now.

Is it necessary to replace the %n sequence in expectAssertionError? Doesn't the format string help with the platform sensitivity?

In this case format() can't help because javax.xml.parsers.DocumentBuilder always parse \r\n as \n.
Let's look at this test case tightly: we have a test XML

String testXml = String.format("<a>%nx <b/>%n</a>");

which one will be format in Windows to "<a>\r\nx <b/>\r\n</a>".
After that this model will be parsed by javax.xml.parsers.DocumentBuilder in org.xmlunit.util.Convert#toDocument(javax.xml.transform.Source, javax.xml.parsers.DocumentBuilderFactory) method.
DocumentBuilder always parse both \r\n and \n as \n. So we will have Document with two nodes with values \nx and \n (I checked this by debugging).
DiffBuilder will find difference between \nx in actual document and x in expected document and throw out comparison result with message "Expected text value 'x' but was '\nx '".
If we will expect formatted line "Expected text value 'x' but was '%nx '" than %n will be convert to \r\n and assertion will fail.

That's why we should use \n instead of %n in ExpectedException configuration.

Ah, I see. I didn't realize the messages the tests are asserting contain actual XML snippets.

Thank you