Skip to content
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

Break optional/ into more granular directories. #590

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 7 additions & 9 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -76,15 +76,13 @@ Here is a single *test case*, containing one or more tests:

### Subdirectories Within Each Draft

There is currently only one additional subdirectory that may exist within each draft test directory.
There are currently four additional subdirectories that may exist within draft directories.
They are:

This is:

1. `optional/`: Contains tests that are considered optional.

Note, the `optional/` subdirectory today conflates many reasons why a test may be optional -- it may be because tests within a particular file are indeed not required by the specification but still potentially useful to an implementer, or it may be because tests within it only apply to programming languages with particular functionality (in
which case they are not truly optional in such a language).
In the future this directory structure will be made richer to reflect these differences more clearly.
1. `should/`: Contain tests which the specification designates as recommended behavior, either explicitly or otherwise clearly
2. `may/`: Contains tests which the specification designates as optional behavior, again explicitly or otherwise clearly
3. `additional/`: Contains additional tests or subdirectories whose applicability is left for implementations to confirm, either because they test additional vocabularies, apply only to certain languages or environments, or because the strength of their recommendation isn't clear from the specification
4. `alternatives/`: Contains additional subdirectories of tests which are mutually exclusive to each other. Implementations should often elect a single file within each directory, corresponding to the choice they have made. As a concrete example, the specification in draft 2020 dictates that given `{"$vocabulary": {"foo": false}, ...}`, all implementations regardless of whether they support `"foo"` should proceed with processing. The validation result, however, now depends on whether the implementation understands the vocabulary or not, so the `alternatives` directory has files for each possibility (though not including the third possibility that the implementation disregards the SHOULD and refuses to process the schema entirely).

## Using the Suite to Test a Validator Implementation

Expand Down Expand Up @@ -153,7 +151,7 @@ If your implementation supports multiple versions, run the above procedure for e
```

2. Test cases found within [special subdirectories](#subdirectories-within-each-draft) may require additional configuration to run.
In particular, tests within the `optional/format` subdirectory may require implementations to change the way they treat the `"format"`keyword (particularly on older drafts which did not have a notion of vocabularies).
In particular, tests within the `additional/format-assertion` subdirectory may require implementations to change the way they treat the `"format"`keyword (particularly on older drafts which did not have a notion of vocabularies).

### Invariants & Guarantees

Expand Down
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
[
{
"description": "schema that uses custom metaschema with format-assertion: false",
"comment": "For implementations which support the format assertion vocabulary",
"schema": {
"$id": "https://schema/using/format-assertion/false",
"$schema": "http://localhost:1234/draft2020-12/format-assertion-false.json",
"format": "ipv4"
},
Expand All @@ -21,8 +21,8 @@
},
{
"description": "schema that uses custom metaschema with format-assertion: true",
"comment": "For implementations which support the format assertion vocabulary",
"schema": {
"$id": "https://schema/using/format-assertion/true",
"$schema": "http://localhost:1234/draft2020-12/format-assertion-true.json",
"format": "ipv4"
},
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
[
{
"description": "schema that uses custom metaschema with format-assertion: false",
"comment": "For implementations which do not support the format assertion vocabulary",
"schema": {
"$schema": "http://localhost:1234/draft2020-12/format-assertion-false.json",
"format": "ipv4"
},
"tests": [
{
"description": "format-assertion: false: valid string",
"data": "127.0.0.1",
"valid": true
},
{
"description": "format-assertion: false: invalid string",
"data": "not-an-ipv4",
"valid": true
}
]
}
]
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
[
{
"description": "schema that uses custom metaschema with format-assertion: false",
"comment": "For implementations which support the format assertion vocabulary",
"schema": {
"$id": "https://schema/using/format-assertion/false",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is removing the $id going to break things? (cc: @karenetheridge) (seen in several places)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am pretty sure no, it's just an extra unneeded validator that was in these schemas.

"$schema": "http://localhost:1234/draft-next/format-assertion-false.json",
"$schema": "http://localhost:1234/draft2020-12/format-assertion-false.json",
"format": "ipv4"
},
"tests": [
Expand All @@ -21,9 +21,9 @@
},
{
"description": "schema that uses custom metaschema with format-assertion: true",
"comment": "For implementations which support the format assertion vocabulary",
"schema": {
"$id": "https://schema/using/format-assertion/true",
"$schema": "http://localhost:1234/draft-next/format-assertion-true.json",
"$schema": "http://localhost:1234/draft2020-12/format-assertion-true.json",
"format": "ipv4"
},
"tests": [
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
[
{
"description": "schema that uses custom metaschema with format-assertion: false",
"comment": "For implementations which do not support the format assertion vocabulary",
"schema": {
"$schema": "http://localhost:1234/draft2020-12/format-assertion-false.json",
"format": "ipv4"
},
"tests": [
{
"description": "format-assertion: false: valid string",
"data": "127.0.0.1",
"valid": true
},
{
"description": "format-assertion: false: invalid string",
"data": "not-an-ipv4",
"valid": true
}
]
}
]
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
[
{
"description": "ECMA 262 regex $ does not match trailing newline",
"comment": "§6.4: ' These regular expressions SHOULD be valid according to the regular expression dialect described in ECMA-262, section 21.2.1'",
"schema": {
"type": "string",
"pattern": "^abc$"
Expand Down
77 changes: 77 additions & 0 deletions tests/draft7/alternatives/content/annotation.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
[
{
"description": "validation of string-encoded content based on media type",
"schema": {
"contentMediaType": "application/json"
},
"tests": [
{
"description": "a valid JSON document",
"data": "{\"foo\": \"bar\"}",
"valid": true
},
{
"description": "an invalid JSON document",
"data": "{:}",
"valid": true
},
{
"description": "ignores non-strings",
"data": 100,
"valid": true
}
]
},
{
"description": "validation of binary string-encoding",
"schema": {
"contentEncoding": "base64"
},
"tests": [
{
"description": "a valid base64 string",
"data": "eyJmb28iOiAiYmFyIn0K",
"valid": true
},
{
"description": "an invalid base64 string (% is not a valid character)",
"data": "eyJmb28iOi%iYmFyIn0K",
"valid": true
},
{
"description": "ignores non-strings",
"data": 100,
"valid": true
}
]
},
{
"description": "validation of binary-encoded media type documents",
"schema": {
"contentMediaType": "application/json",
"contentEncoding": "base64"
},
"tests": [
{
"description": "a valid base64-encoded JSON document",
"data": "eyJmb28iOiAiYmFyIn0K",
"valid": true
},
{
"description": "a validly-encoded invalid JSON document",
"data": "ezp9Cg==",
"valid": true
},
{
"description": "an invalid base64 string that is valid JSON",
"data": "{}",
"valid": true
},
{
"description": "ignores non-strings",
"data": 100,
"valid": true
}
]
}
]