leadpony / jsonp-test-suite Goto Github PK

I'm checking an implementation of JsonP I'm writing based on Jackson and got these two errors:

Expected :"hello\u000bworld"
Actual   :"hello\u000Bworld"

Expected :"hello\u001bworld"
Actual   :"hello\u001Bworld"

Both of these should be correct, I think.

I can't change the escaping because I'm relying on the underlying Jackson code.

Some of the tests require that objects serialize their output in a particular order. These comparisons would be better if they compared the JSON in an order-independent way.

According to the JSON grammar, there needs to be at least one thing, be it an object, value, or array. Shouldn't a parsing exception (EOF) be thrown for these? hasNext(), in addition to next(), throws a JsonParsingException when it advances to the next event, and since the parser encounters an EOF before the next event, it's technically invalid JSON.

Ref: https://tools.ietf.org/html/rfc8259#section-2

JSON-text = ws value ws

Referring to these cases in JsonGeneratorTest

    enum DoubleTestCase {
        ZERO(0.0, "0.0"),
        E(Math.E, "2.718281828459045"),
        PI(Math.PI, "3.141592653589793"),
        MAX_VALUE(Double.MAX_VALUE, "1.7976931348623157E308"),
        MIN_VALUE(Double.MIN_VALUE, "4.9E-324");

isn't the MAX_VALUE one also legal if there's a + between the E and 308?

It looks like the JSON grammar allows no character, a plus, or a minus.

Some implementations output "\uXXXX" variants for non-ASCII characters (eg. the "G-clef" example, "\ud834\udd1e"). It might be more useful, in the tests that compare strings, to normalize to ASCII-only before the comparison. Another example: the em-dash (U+2014) in atom-api.json.

The Javadocs for JsonPointer don't say that the target can't be modified. What leads me to believe this isn't an oversight is that the JsonPatch Javadocs say explicitly that the target isn't modified, so my thinking is that the omission was on purpose.

I've written my JsonPointer implementation to modify the target, and I think this behaviour is the intended one, at least it's my working assumption.

It would be nice if the failing/errored tests used zero-based indexes when printing which data caused the failure (instead of 1-based indexes). Or is this in the test container and not in your code?

I was wondering why unknown properties are expected to be removed from the config in the various factory tests? This doesn't seem like expected behaviour.

I believe the string should be "\\ud834\\udd1e\". i.e. escape the slashes because all the other test cases do.

These should be false since their syntax is invalid.

There are a number of places where thrown is retrieved from the test and then thrown.getMessage() is called. These places should first check for thrown == null to avoid a possible NullPointerException; these cases will result in a test error but should instead result in a failure.

Similar to #9, since hasNext() is used to check for a next event, and since there's no next event because of an unexpected EOF, shouldn't a JsonParsingException be thrown instead? I'm wondering why this behaviour should be any different than the exceptions expected from the other test cases in these lists (JsonExclusiveBadTerminationTestCase and BadTerminationTestCase).

Open question: When should hasNext() return false and when should it throw an exception due to malformed JSON, i.e. EOF?
Personally, I believe that an unexpected EOF violates the JSON grammar and should cause a parsing exception, and the only time hasNext() should return false is at the end of input.