You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+4-6Lines changed: 4 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -79,15 +79,13 @@ Here is a single *test case*, containing one or more tests:
79
79
80
80
### Subdirectories Within Each Version directory
81
81
82
-
There is currently only one additional subdirectory that may exist within each specification version test directory.
82
+
A specification version test directory may contain one or more subdirectories.
83
83
84
-
This is:
84
+
These are:
85
85
86
-
1.`optional/`: Contains tests that are considered optional.
86
+
1.`optional/`: Contains tests that are considered optional. Note that this subdirectory currently 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.
87
87
88
-
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
89
-
which case they are not truly optional in such a language).
90
-
In the future this directory structure will be made richer to reflect these differences more clearly.
88
+
2.`proposals/`: Contains a subfolder for each active proposal to the specification. If the proposal is a keyword (generally the case), then the subfolder will bear the name of that keyword. Inside the proposal subfolder is a series of test files that would contain amendments to the required test suite should the proposal be incorporated into the specification. These test should be considered volitile while the proposal is in development, however implementations claiming to support the proposal are expected to pass its tests.
91
89
92
90
## Using the Suite to Test a Validator Implementation
"description": "A schema for files contained within this suite",
5
-
6
5
"type": "array",
7
6
"minItems": 1,
8
7
"items": {
9
8
"description": "An individual test case, containing multiple tests of a single schema's behavior",
10
-
11
9
"type": "object",
12
-
"required": [ "description", "schema", "tests" ],
10
+
"required": [
11
+
"description",
12
+
"schema",
13
+
"tests"
14
+
],
13
15
"properties": {
14
16
"description": {
15
17
"description": "The test case description",
@@ -25,67 +27,76 @@
25
27
"tests": {
26
28
"description": "A set of related tests all using the same schema",
27
29
"type": "array",
28
-
"items": { "$ref": "#/$defs/test" },
30
+
"items": {
31
+
"$ref": "#/$defs/test"
32
+
},
29
33
"minItems": 1
30
34
},
31
-
"specification":{
35
+
"specification":{
32
36
"description": "A reference to a specification document which defines the behavior tested by this test case. Typically this should be a JSON Schema specification document, though in cases where the JSON Schema specification points to another RFC it should contain *both* the portion of the JSON Schema specification which indicates what RFC (and section) to follow as *well* as information on where in that specification the behavior is specified.",
33
-
34
37
"type": "array",
35
38
"minItems": 1,
36
39
"uniqueItems": true,
37
-
"items":{
40
+
"items":{
38
41
"properties": {
39
-
"core": {
42
+
"core": {
40
43
"description": "A section in official JSON Schema core drafts",
0 commit comments