Add tests from JSONTestSuite #140
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Note These results are affected by shared workloads on GitHub runners. Use the results only to detect possible regressions, but always rerun on more stable machine before making any conclusions! Benchmark results (pull-request, 02e873c)Benchmark results (master, 7bc09ac) |
gavlyukovskiy
force-pushed
the
json-test-suite
branch
from
c4a582d
to
db8feaf
Compare
gavlyukovskiy
force-pushed
the
json-test-suite
branch
from
db8feaf
to
02e873c
Compare
|
|
@Breus looks like that badge is going to get a little bit more impressive π |
donavdey
approved these changes
May 17, 2024
Breus
approved these changes
May 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds all tests from
JSONTestSuite. That suite has 3 types of tests:y_*are valid JSONsi_*are invalid JSONs that are allowed to be parsed, usually some large numbers and/or invalid UTF-8 sequencesn_*are invalid JSONs, for this the normal parser should fail, however we can process all of them except 2 that have 100k nesting level (P.S. Don't try opening them in IDEA π)I've copied all of them to our repository and established following test cases
mustPassSuiteWithNoopMaskerShouldBeEquivalentToJackson
y_*tests must pass. I'm usingValueMaskers.withRawValueFunction(value -> value)as a more complicated noop masker to make sure that we always correctly track values, transform them to strings and back to bytes. The results of this are equivalent when parsed by JacksonmayPassSuiteWithNoopMaskerShouldNotFail
i_*tests must not fail with and ideally should be equivalent to how Jackson parses it (if it can). There are 4 exceptions whenjava.lang.Stringtreats invalid UTF-8 characters differently than Jackson doesmustFailSuiteWithNoopMaskerShouldOnlyFailWithInvalidJsonException
n_*tests must fail for a normal JSON parser, however we allow it not to fail, but if it does fail, then it must be withInvalidJsonException. WithValueMaskers.withRawValueFunction(or default masking options) there are only 2 test cases that are failing due to internalStackOverFlowError.shouldMaskAllTestCasesPredictably
For all test files (including
n_*) I've simply asserted the masker json we currently produce.mustPassSuiteWithNoopTextFunction
Verifies that all test files that contain correct UTF-8 sequences we properly decode it in
withTextValueFunction. There are 26i_*test files where we fail on converting invalid sequences.For the
withTextValueFunctionfunction the question is whether we should continue to fail on those 26 test cases or take the behavior ofjava.lang.Stringof converting most invalid sequences intoοΏ½and passing that to the user provided function?Fixes
This PR has couple of fixes for cases when we get out of bounds or throw internal exception instead of
InvalidJsonException. All of the fixes only apply ton_*andi_*test cases, nothing critical was found during the testing πHard decisions time!
The main problem is what to do with
n_*test cases?The main problem is that we're not actually parsing the values so we do not reject things like invalid numbers or invalid escapes (except for
withTextValueFunction. We also do not fail on invalid json structures - for example in arrays we don't strictly need to see a comma and ignore anything unknown and mask values if we detect them. With that for most of the test cases we actually mask them in more or less predictable ways, for example[""->["***"(n_array_unclosed.json)[ , ""]->[ , "***"](n_array_missing_value.json)However some test cases are leaking information or giving weird results
abc->abc(n_string_single_string_no_double_quotes.json) when string doesn't have quotes then we simply leave it as is['single quote']->['single quo"&&&"(n_string_single_quote.json) we ignore the value started with a single quote and accidentally think that we've found a boolean to maskIn
shouldMaskAllTestCasesPredictablyI've asserted the current status, so it would be useful to go over them and decide whether we should do anything special about each one of those.Closes #121