search

frizbog / gedcom4j

Java library for reading/writing genealogy files in GEDCOM format
http://gedcom4j.org
54 stars 36 forks source link

A few of the JUnit tests fail to run on Windows platform #126

Closed Psyches closed 8 years ago

Psyches commented 8 years ago

Here are the failing tests that seem to be Windows-related, with some failure results:

org.gedcom4j.writer.Issue89Test:testIssue89(org.gedcom4j.writer.Issue89Test)

junit.framework.ComparisonFailure: expected:<0 HEAD[
1 SOUR UNSPECIFIED
1 SUBM @SUBM0001@
1 SUBN @SUBN0001@

...

but was:<0 HEAD[ 1 SOUR UNSPECIFIED 1 SUBM @SUBM0001@ 1 SUBN @SUBN0001@ ...

org.gedcom4j.writer.GedcomWriterFileProgressAndCancellationTest

testNoCancellationUnicodeLittleEndian(org.gedcom4j.writer.GedcomWriterFileProgressAndCancellationTest)

java.lang.AssertionError: expected:<1203632> but was:<1243676>

testNoCancellationAnsel(org.gedcom4j.writer.GedcomWriterFileProgressAndCancellationTest)

java.lang.AssertionError: expected:<601799> but was:<621821>

testNoCancellationAscii(org.gedcom4j.writer.GedcomWriterFileProgressAndCancellationTest)

java.lang.AssertionError: expected:<601799> but was:<621821>

testNoCancellationUtf8(org.gedcom4j.writer.GedcomWriterFileProgressAndCancellationTest)

java.lang.AssertionError: expected:<581632> but was:<606208>

testNoCancellationUnicodeBigEndian(org.gedcom4j.writer.GedcomWriterFileProgressAndCancellationTest)

java.lang.AssertionError: expected:<1203626> but was:<1243670>

org.gedcom4j.writer.Issue97Test:testIssue97(org.gedcom4j.writer.Issue97Test)

org.junit.ComparisonFailure: expected:<0 HEAD[
1 SOUR UNSPECIFIED
1 SUBM @SUBM0001@
1 SUBN @SUBN0001@

...

but was:<0 HEAD[ 1 SOUR UNSPECIFIED 1 SUBM @SUBM0001@ 1 SUBN @SUBN0001@ ...

Psyches commented 8 years ago

That is, the 7 failures are 2 hard-coded string tests with embedded line delimiters (the first and last), and 5 character encoding tests all in a single JUnit test class (separated by method name). I didn't dig into the 5, which are all strictly bytesWritten differences (all line counts etc are correct).

Psyches commented 8 years ago

FYI, I've worked around these locally. In the Encoding tests:

private final boolean isLongEOL = System.getProperty("line.separator").length() > 1;

and then in the bytesWritten assert, something like (this one for bigEndianUnicode):

assertEquals(isLongEOL ? (1203626 + 20022 * 2) : 1203626, bytesWritten);

for the String hard-codes compared with file Writer output, e.g. Issue97Test:

String output = baos.toString().replaceAll("\r", "");
frizbog commented 8 years ago

Those seem like good and reasonable fixes - can you submit a pull request with those changes?

frizbog commented 8 years ago

It's actually worse than this. A number of well-formed files won't load under Windows. Because the code was written on a Mac system, it doesn't correctly handle line terminators for Windows in a number of locations. I will be working on this soon.

frizbog commented 8 years ago

I've corrected things so they work on Mac and Windows.

To do so, I did have to introduce a new property on GedcomWriter that lets you set the style of line terminator you want (and passes it through to GedcomFileWriter which already had a property for this, but it wasn't exposed to callers). This backward-compatible API change is going to require changing the version number to 3.1.0.

frizbog commented 8 years ago

v3.1.0-SNAPSHOT released to Maven Central

frizbog commented 8 years ago

v3.1.0 released.