-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[Feature] Support for JSON minimum
, maximum
, exclusiveMinimum
, and exclusiveMaximum
#1023
Conversation
Co-authored-by: Michał Moskal <[email protected]>
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files@@ Coverage Diff @@
## main #1023 +/- ##
==========================================
- Coverage 70.25% 63.04% -7.22%
==========================================
Files 62 63 +1
Lines 4472 4670 +198
==========================================
- Hits 3142 2944 -198
- Misses 1330 1726 +396 ☔ View full report in Codecov by Sentry. |
minimum
, maximum
, exclusiveMinimum
, and exclusiveMaximum
minimum
, maximum
, exclusiveMinimum
, and exclusiveMaximum
Note: we have one xfail here due to the fact that JSON apparently allows trailing Ready for review. |
Another note: JSON Schema Draft4 has a slightly different convention around Currently, our Draft202012 validator will reject these schemas, so we should be safe not to handle that case internally. Allowing Draft4 might open a bit of a can of worms, so I want to punt on that for at least a while. |
@riedgar-ms let me know if you're satisfied with the tests here :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main concern is the lack of negative number tests in TestBoundedNumeric
.
*(5.0, {"type": "integer", "minimum": 5}, True), | ||
marks=pytest.mark.xfail(reason="JSON technically allows trailing zeroes, but we currently don't") | ||
), | ||
(5.1, {"type": "integer", "minimum": 5}, False), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Integer" and "5.1" .... is this telling me something about JSON schema that I don't want to know?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't worry, this is a "should fail" case (see the False in the third slot of the tuple 😄)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably should have made the comment on the previous line :-) The 'reason' gives me bad feelings about potentially subtle bugs (but we have to follow the JSON standard, so 🤷)
(9.9, {"type": "number", "exclusiveMinimum": 5.0, "exclusiveMaximum": 10.0}, True), | ||
# --- Edge cases --- | ||
(0, {"type": "integer", "minimum": 0}, True), | ||
(-1, {"type": "integer", "minimum": 0}, False), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason that these are the only tests of negative numbers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that was a terrible oversight on my part. There are a lot more test cases on the underlying regex_utils, but I'll make sure to get some populated in the higher-level json tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just the core cases should be enough. Don't need to re-test everything exhaustively.
(6, {"type": "integer", "maximum": 5.5}, False), | ||
(5, {"type": "integer", "exclusiveMaximum": 5.5}, True), | ||
(6, {"type": "integer", "exclusiveMaximum": 5.5}, False), | ||
# --- Large numbers --- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add a bunch more large number and precision cases (as I think manically about how floating point can really Mess You Up), but I wouldn't worry right now.
if not right_inclusive and right_int == right: | ||
right_int -= 1 | ||
do_test_int_range(rx, left_int, right_int, left_none, right_none) | ||
eps = 0.000001 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a float
epsilon, not a double
one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was just supposed to be a small number. I think we could probably test with 0.0000000001 all way down to 0.1 each 10x or something. AFAIK JSON schema doesn't say numbers are doubles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't worry about that right now; my main concern is having more negative numbers in the main test cases. I have the impression that JSON may be a bit relaxed in its concepts of floating point.
@riedgar-ms added some negative test cases. Will merge once I see some green :) |
JSON support for integer and float bounds.
Closes #1019 (thanks for the code @mmoskal!)