More field validation tests #1068
Merged
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.
For {extension,non-extension} {singular,repeated} fields, check range and type
checks.
All fields with range checks are tested. For type and nullability checks we
only use a message and a
boolfield, as there are too many types of fieldsand most of them use the same validation function.
Fields with range checks are not tested for type and nullability checks. To
check whether a value is within range we have to use as a non-null
intordouble, so if the value being checked doesn't have the right type the rangecheck function will throw anyway.
This reveals two inconsistencies in the library:
When type of a non-repeated extension value is not right we throw an argument
error instead of a type error.
setExtensiontakes anObject(not nullable) as an argument butaddExtensiontakesObject?(nullable).I tested accordingly instead of trying to fix the inconsistencies as fixing
them will break downstream.