Some tests fail on Windows due to line.separator differences

[joelittlejohn]

Original author: [email protected] (July 04, 2012 21:29:38)

line.separator on Windows is \r\n, but static test case data assumes \n.

What steps will reproduce the problem?

1. cd jsonschema2pojo-core
2. mvn test

What is the expected output?

Results :

Tests run: 75, Failures: 0, Errors: 0, Skipped: 0

What do you see instead?

Failed tests:
applyWithNoAdditionalPropertiesAllowed(com.googlecode.jsonschema2pojo.rules.AdditionalPropertiesRuleTest):
applyWithDefaultAdditionalProperties(com.googlecode.jsonschema2pojo.rules.AdditionalPropertiesRuleTest):
applyWithAdditionalPropertiesStringSchema(com.googlecode.jsonschema2pojo.rules.AdditionalPropertiesRuleTest):
applyWithAdditionalPropertiesObjectSchema(com.googlecode.jsonschema2pojo.rules.AdditionalPropertiesRuleTest):
applyCreatesTextEnum(com.googlecode.jsonschema2pojo.rules.EnumRuleTest):
applyCreatesTextEnumWithSpaces(com.googlecode.jsonschema2pojo.rules.EnumRuleTest):
applyCreatesNumberEnum(com.googlecode.jsonschema2pojo.rules.EnumRuleTest):

Sample individual test:

java.lang.AssertionError:
Expected: "public class DummyClass {\n\n\n}\n"
got: "public class DummyClass {\r\n\r\n\r\n}\r\n"

at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:21)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at com.googlecode.jsonschema2pojo.rules.AdditionalPropertiesRuleTest.applyWithNoAdditionalPropertiesAllowed(AdditionalPropertiesRuleTest.java:101)

What version of the product are you using? On what Java version?

Tried tests on:

Windows - failed.
Ubuntu - passed.

Original issue: http://code.google.com/p/jsonschema2pojo/issues/detail?id=56

[joelittlejohn]

From [email protected] on July 04, 2012 21:36:41
Thanks Paul. These tests are of really dubious value. The unit tests that check for specific output strings are horribly fragile and suffer from problems like this.

I've been slowly migrating all these unit tests to integration tests that check that (for a given schema) the expected construct is present in compiled code. It's much clearer what schema input examples are being tested and what the expected Java result is. Tests for this project really shouldn't care what the exact source representation is, only that a correct Java API is created.

This final unit test remains as I haven't yet created the corresponding integration test. To fix this issue though, I create that IT and delete this test.

[joelittlejohn]

From [email protected] on July 04, 2012 21:37:34
s/I create/I'll create/

[joelittlejohn]

From [email protected] on July 04, 2012 21:45:24
No problem, Joe.

I realised that it was something affecting the test class itself rather than the real code, but thought I'd raise it to you anyway for visibility.

Appreciate the quick response!

[joelittlejohn]

From [email protected] on July 24, 2012 22:08:57
Fixed. I don't have a Windows machine to test this on, but failed tests listed above have been removed/replaced.