@@ -11,27 +11,103 @@ validation libraries can use to test their validators.
11
11
It is meant to be language agnostic and should require only a JSON parser.
12
12
13
13
The conversion of the JSON objects into tests within your test framework of
14
- choice is still the job of the validator implementor.
15
-
16
- ## Structure of a Test
14
+ choice is the job of the validator implementor.
15
+
16
+ ## Table of Contents
17
+
18
+ 1 . [ Test Concepts] ( #test-concepts )
19
+ 2 . [ Introduction to the Test Suite Structure] ( #introduction-to-the-test-suite-structure )
20
+ 1 . [ Definitions and Requirements] ( #definitions-and-requirements )
21
+ 2 . [ Draft Test Subdirectories] ( #draft-test-subdirectories )
22
+ 3 . [ Coverage] ( #coverage )
23
+ 4 . [ How to Utilize the Tests] ( #how-to-utilize-the-tests )
24
+ 1 . [ How to Implement a Test Runner] ( #how-to-implement-a-test-runner )
25
+ 2 . [ Test Suite Assumptions] ( #test-assumptions )
26
+ 5 . [ Who Uses the Test Suite] ( #who-uses-the-test-suite )
27
+ 1 . [ Clojure] ( #clojure )
28
+ 2 . [ Coffeescript] ( #coffeescript )
29
+ 3 . [ C++] ( #c++ )
30
+ 4 . [ Dart] ( #dart )
31
+ 5 . [ Elixir] ( #elixir )
32
+ 6 . [ Erlang] ( #erlang )
33
+ 7 . [ Go] ( #go )
34
+ 8 . [ Haskell] ( #haskell )
35
+ 9 . [ Java] ( #java )
36
+ 10 . [ JavaScript] ( #javascript )
37
+ 11 . [ Node.js] ( #node.js )
38
+ 12 . [ .NET] ( #.net )
39
+ 13 . [ PHP] ( #php )
40
+ 14 . [ PostgreSQL] ( #postgresql )
41
+ 15 . [ Python] ( #python )
42
+ 16 . [ Ruby] ( #ruby )
43
+ 17 . [ Rust] ( #rust )
44
+ 18 . [ Swift] ( #swift )
45
+ 6 . [ Contributing] ( #contributing )
46
+ 7 . [ Resources] ( #resources )
47
+
48
+ ## Test Concepts
49
+
50
+ This set of tests can test anything that a JSON Schema can describe. It
51
+ currently does not provide a mechanism for testing anything that a JSON Schema
52
+ cannot describe.
53
+
54
+ For example, a schema can require that a string is a _ URI-reference_ and even
55
+ that it matches a certain pattern, but it is not currently possible to require
56
+ that the URI is normalized.
57
+
58
+ This means there are limitations when using a draft's meta-schema as the schema
59
+ in a _ test case_ .
60
+
61
+ ## Introduction to the Test Suite Structure
17
62
18
63
The tests in this suite are contained in the ` tests ` directory at the root of
19
64
this repository. Inside that directory is a subdirectory for each draft or
20
- version of the specification.
65
+ version of the specification.\
66
+ _ Summary: There are tests for each draft._
21
67
22
- Inside each draft directory, there are a number of ` .json ` files and one or more
68
+ Inside each draft directory there are a number of ` .json ` files and one or more
23
69
special subdirectories. The subdirectories contain ` .json ` files meant for a
24
- specific testing purpose, and each ` .json ` file logically groups a set of test
25
- cases together. Often the grouping is by property under test, but not always.
26
-
27
- The subdirectories are described in the next section.
28
-
29
- Inside each ` .json ` file is a single array containing objects. It's easiest to
30
- illustrate the structure of these with an example:
70
+ specific testing purpose, and each ` .json ` file logically groups a set of _ test
71
+ cases_ together. Often the grouping is by property under test, but not always.\
72
+ _ Summary: There are a number of ` .json ` files for each draft._
73
+
74
+ The subdirectories are described in a following subsection.
75
+
76
+ Each ` .json ` file consists of an array containing a number of _ test cases_ , and
77
+ each _ test case_ is composed of one schema and an array of _ tests_ .
78
+
79
+ ### Definitions and Requirements
80
+
81
+ An outline of the definitions and requirements follows.
82
+
83
+ 1 . _ Test_ : A single test contains a description, an instance, and a Boolean that
84
+ indicates whether that instance is considered valid against the associated
85
+ schema. The required properties are:
86
+ 1 . ` "description" ` : The test description.
87
+ 2 . ` "data" ` : The instance to validate against the schema.
88
+ 3 . ` "valid" ` : The expected validation result. A test is considered to pass if
89
+ the actual validation result matches this value, and is considered to fail
90
+ otherwise. Note that this value is only applicable for testing the
91
+ contents of ` "data" ` and is not applicable for testing the contents of
92
+ ` "schema" ` from the _ test case_ .
93
+ 2 . _ Test Case_ : One schema plus a list of _ tests_ . The required properties are:
94
+ 1 . ` "description" ` : The test case description.
95
+ 2 . ` "schema" ` : The schema against which all the test instances (` "data" ` )
96
+ are validated. This should be valid and loadable.
97
+ 3 . ` "tests" ` : An array of _ tests_ .
98
+ 3 . _ Test Runner_ : A program that tests a validator implementation using the
99
+ tests in this suite.
100
+
101
+ The term _ Test Suite_ is left undefined in this section because different
102
+ testing frameworks or testing approaches may refer to a "suite" as the entire
103
+ set of tests or merely as a grouping of test cases. However, this document
104
+ refers to all the tests for all the drafts as the _ Test Suite_ .
105
+
106
+ A _ test case_ example:
31
107
32
108
``` json
33
109
{
34
- "description" : " The description of the test case" ,
110
+ "description" : " The test case description " ,
35
111
"schema" : {
36
112
"description" : " The schema against which the data in each test is validated" ,
37
113
"type" : " string"
@@ -51,18 +127,17 @@ illustrate the structure of these with an example:
51
127
}
52
128
```
53
129
54
- In short: a description, a schema under test, and some tests, where each test
55
- in the ` tests ` array is an objects with a description of the case itself, the
56
- instance under test, and a boolean indicating whether it should be valid
57
- or invalid.
130
+ ### Draft Test Subdirectories
58
131
59
- ## Test Subdirectories
60
-
61
- There is currently only one subdirectory that may exist within each draft
132
+ There is currently only one subdirectory that may exist within each draft test
62
133
directory. This is:
63
134
64
135
1 . ` optional/ ` : Contains tests that are considered optional.
65
136
137
+ This structure is in flux and may be amended in the future. For example, maybe
138
+ there will be one subdirectory underneath ` optional/ ` for each feature, for
139
+ example, ` optional/format/ ` for ` "format" ` -specific tests. This is evolving.
140
+
66
141
## Coverage
67
142
68
143
All JSON Schema specification releases should be well covered by this suite,
@@ -81,6 +156,93 @@ any draft still accepting bug fixes, please
81
156
[ file an issue] ( https://github.com/json-schema-org/JSON-Schema-Test-Suite/issues )
82
157
or [ submit a PR] ( https://github.com/json-schema-org/JSON-Schema-Test-Suite ) .
83
158
159
+ ## How to Utilize the Tests
160
+
161
+ The test suite structure was described
162
+ [ above] ( #introduction-to-the-test-suite-structure ) . This section describes:
163
+
164
+ 1 . How to implement a test runner for testing a validator implementation.
165
+ 2 . Assumptions the test suite makes and their rationales.
166
+
167
+ Note that the specific steps described here outline a procedure for running the
168
+ tests. The procedure doesn't need to be followed exactly, but the results of
169
+ your own procedure should produce the same effects.
170
+
171
+ After completing the tests, each test is marked as one of:
172
+ 1 . Pass
173
+ 2 . Fail
174
+ 3 . Not Executed
175
+
176
+ ### How to Implement a Test Runner
177
+
178
+ To test a specific draft, walk the filesystem tree for that draft and execute
179
+ all the tests in each ` .json ` file encountered. Each ` .json ` file is either
180
+ located in the root of the draft test hierarchy or in a subdirectory. The
181
+ approach is similar for both cases, but tests found in subdirectories need to
182
+ follow the assumptions and restrictions for the containing subdirectory.
183
+
184
+ For each _ test case_ in a ` .json ` file:
185
+ 1 . Load the schema from ` "schema" ` .
186
+ 1 . If the schema is loaded successfully then it can be used for each test.
187
+ 2 . If the schema is not loaded successfully or is found to be invalid, all
188
+ _ tests_ in this _ test case_ should be marked as "Not Executed". It is not
189
+ correct to assume that ` "valid" ` is false for these tests.
190
+ 2 . For each _ test_ in the _ test case_ :
191
+ 1 . Apply the schema to the instance found in ` "data" ` .
192
+ 2 . The test passes if the schema application result matches the Boolean value
193
+ found in ` "valid" ` .
194
+ 3 . The test fails if the result does not match the value found in ` "valid" ` .
195
+
196
+ ### Test Suite Assumptions
197
+
198
+ There are a few assumptions that the test suite makes around the structure of
199
+ the tests and around schema loading and application.
200
+
201
+ 1 . A schema, the contents of ` "schema" ` in a _ test case_ , should be valid
202
+ and loadable.
203
+
204
+ The rationale behind this is that we are testing instances in a _ test's_
205
+ ` "data" ` element, and not the schema itself. There is currently no mechanism
206
+ for testing a schema unless the schema is represented as an instance inside
207
+ a _ test_ and the associated meta-schema is used as a ` "$ref" ` inside a
208
+ _ test case_ . For example:
209
+
210
+ ``` json
211
+ {
212
+ "description" : " Test the \" type\" schema keyword" ,
213
+ "schema" : {
214
+ "$ref" : " https://json-schema.org/draft/2019-09/schema"
215
+ },
216
+ "tests" : [
217
+ {
218
+ "description" : " Valid: string" ,
219
+ "data" : {
220
+ "type" : " string"
221
+ },
222
+ "valid" : true
223
+ },
224
+ {
225
+ "description" : " Invalid: null" ,
226
+ "data" : {
227
+ "type" : null
228
+ },
229
+ "valid" : false
230
+ }
231
+ ]
232
+ }
233
+ ```
234
+
235
+ Even then, if it can't be represented by the JSON Schema language, then it is
236
+ not currently possible to test. For example, it is not possible to test that a
237
+ URI-reference is normalized.
238
+ 2 . Any tests in a subdirectory of a specific draft's test suite is handled a
239
+ little differently than the tests in a draft's root directory.
240
+
241
+ The ` optional/ ` subdirectory contains tests that test concepts that are not
242
+ required by the specification. For these tests, it is necessary to enable
243
+ features that would not otherwise be required. For example, some of the
244
+ optional tests require that a validator's ` "format" ` features be enabled.
245
+
84
246
## Who Uses the Test Suite
85
247
86
248
This suite is being used by:
@@ -218,3 +380,9 @@ There are some sanity checks in place for testing the test suite. You can run
218
380
them with ` bin/jsonschema_suite check ` or ` tox ` . They will be run automatically
219
381
by [ GitHub Actions] ( https://github.com/json-schema-org/JSON-Schema-Test-Suite/actions?query=workflow%3A%22Test+Suite+Sanity+Checking%22 )
220
382
as well.
383
+
384
+ ## Resources
385
+
386
+ 1 . [ JSON Schema Test Suite] ( https://github.com/json-schema-org/JSON-Schema-Test-Suite )
387
+ 2 . [ JSON Schema] ( https://json-schema.org )
388
+ 3 . [ RFC 3986] ( https://www.rfc-editor.org/rfc/rfc3986.html )
0 commit comments