specification¶

This determines the draft version of the schema to confirm compliance to. Possible values are:

• "draft3"
• "draft4"
• "draft6"
• "draft7"
• "draft2019-09"
• "latest" (alias for "draft2019-09")

The default is "latest", but in the synopsis example, JSON::Schema is testing draft 3 compliance.

(For backwards compatibility, "new" can be called with a single numeric argument of 3 to 7, which maps to "draft3" through "draft7".)

test_dir¶

Instead of specifying a draft specification to test against, which will select the most appropriate tests, you can pass in the name of a directory of tests to run directly. Files in this directory should be .json files following the format described in <https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/master/README.md>.

additional_resources¶

A directory of additional resources which should be made available to the implementation under the base URI "http://localhost:1234". This is automatically provided if you did not override "/test_dir"; otherwise, you need to supply it yourself, if any tests require it (for example by containing "{"$ref": "http://localhost:1234/foo.json/#a/b/c"}"). If you supply an "add_resource" value to "acceptance" (see below), this will be done for you.

verbose¶

Optional. When true, prints version information and test result table such that it is visible during "make test" or "prove".

include_optional¶

Optional. When true, tests in subdirectories (most notably optional/ are also included.

acceptance¶

Accepts a hash of options as its arguments.

(Backwards-compatibility mode: accepts a subroutine which is used as "validate_json_string", and a hashref of arguments.)

Available options are:

validate_data

A subroutine reference, which is passed two arguments: the JSON Schema, and the inflated data structure to be validated.

The subroutine should return truthy or falsey depending on if the schema was valid for the input or not.

Either "validate_data" or "validate_json_string" is required.

validate_json_string

A subroutine reference, which is passed two arguments: the JSON Schema, and the JSON string containing the data to be validated.

The subroutine should return truthy or falsey depending on if the schema was valid for the input or not.

Either "validate_data" or "validate_json_string" is required.

add_resource

Optional. A subroutine reference, which will be called at the start of "acceptance" multiple times, with two arguments: a URI (string), and a data structure containing schema data to be associated with that URI, for use in some tests that use additional resources (see above). If you do not provide this option, you will be responsible for ensuring that those additional resources are made available to your implementation for the successful execution of the tests that rely on them.

For more information, see <https://json-schema.org/draft/2019-09/json-schema-core.html#rfc.section.8.2.4.5>.

tests

Optional. Restricts tests to just those mentioned (the conditions are ANDed together, not ORed). The syntax can take one of many forms:

  # run tests in this file
  tests => { file => 'dependencies.json' }
  # run tests in these files
  tests => { file => [ 'dependencies.json', 'refRemote.json' ] }
  # run tests in this file with this group description
  tests => {
    file => 'refRemote.json',
    group_description => 'remote ref',
  }
  # run tests in this file with these group descriptions
  tests => {
    file => 'const.json',
    group_description => [ 'const validation', 'const with object' ],
  }
  # run tests in this file with this group description and test description
  tests => {
    file => 'const.json',
    group_description => 'const validation',
    test_description => 'another type is invalid',
  }
  # run tests in this file with this group description and these test descriptions
  tests => {
    file => 'const.json',
    group_description => 'const validation',
    test_description => [ 'same value is valid', 'another type is invalid' ],
  }

todo_tests

Optional. Mentioned tests will run as "TODO". Uses arrayrefs of the same hashref structure as "tests" above, which are ORed together.

  todo_tests => [
    # all tests in this file are TODO
    { file => 'dependencies.json' },
    # just some tests in this file are TODO
    { file => 'boolean_schema.json', test_description => 'array is invalid' },
    # .. etc
  ]

results¶

After calling "acceptance", a list of test results are provided here. It is an arrayref of hashrefs with four keys:

• file - the filename
• pass - the number of pass results for that file
• todo_fail - the number of fail results for that file that were marked TODO
• fail - the number of fail results for that file (not including TODO tests)