New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Psyches opened this Issue Aug 14, 2016 · 7 comments

Comments

Projects
None yet
2 participants
@Psyches

Psyches commented Aug 14, 2016

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

This comment has been minimized.

Psyches commented Aug 14, 2016

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).

@frizbog frizbog added the bug label Aug 14, 2016

@Psyches

This comment has been minimized.

Psyches commented Aug 14, 2016

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", "");
  • and that fixed all problems for me.
@frizbog

This comment has been minimized.

Owner

frizbog commented Aug 14, 2016

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

@frizbog

This comment has been minimized.

Owner

frizbog commented Aug 14, 2016

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 frizbog self-assigned this Aug 14, 2016

frizbog added a commit that referenced this issue Aug 14, 2016

frizbog added a commit that referenced this issue Aug 14, 2016

frizbog added a commit that referenced this issue Aug 14, 2016

frizbog added a commit that referenced this issue Aug 14, 2016

frizbog added a commit that referenced this issue Aug 14, 2016

frizbog added a commit that referenced this issue Aug 14, 2016

frizbog added a commit that referenced this issue Aug 14, 2016

Issue #126 - bumped version num, GedcomWriter changes, test fixes
Added the ability to override the line terminator used in GedcomWriter.
The JVM default continues to be the default, but you can change it now.
This is a backward compatible API change, so the minor version had to
change.

frizbog added a commit that referenced this issue Aug 14, 2016

frizbog added a commit that referenced this issue Aug 14, 2016

frizbog added a commit that referenced this issue Aug 14, 2016

Issue #126 - diacritics in the source were having encoding problems
Escaped all non-ascii characters using Unicode to avoid ambiguity
@frizbog

This comment has been minimized.

Owner

frizbog commented Aug 14, 2016

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

This comment has been minimized.

Owner

frizbog commented Aug 14, 2016

v3.1.0-SNAPSHOT released to Maven Central

@frizbog

This comment has been minimized.

Owner

frizbog commented Aug 20, 2016

v3.1.0 released.

@frizbog frizbog closed this Aug 20, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment