Use full schema (schema-base.yaml) in schema.test.mjs #4702
Conversation
There was a problem hiding this comment.
This script is not redundant, it validates both "pass" and "fail" test cases and checks whether they pass or fail as expected.
This is needed in addition to the coverage script, which only runs the "pass" test cases.
Not sure if/how we can fold the "fail" test cases into the coverage script.
Copying the defineVocabulary and registerSchema additions from schema-test-coverage.mjs and validating with schema-base instead of schema works fine.
This script is run by |
Since we are testing with a placeholder, we need to match the placeholder. This will unfortunately need to be different on each new release line branch, so let's separate this test case into its own file.
handrews
changed the title
|
@ralfhandl I have changed this PR to make the same changes as to the other script. It's not idea with the duplication, but please let's get this unblocked first and optimize/refactor later. |
|
BTW the commit to fix the |
| addKeyword({ | ||
| id: "https://spec.openapis.org/oas/schema/vocab/keyword/discriminator", | ||
| interpret: (discriminator, instance, context) => { | ||
| return true; | ||
| }, | ||
| /* discriminator is not exactly an annotation, but it's not allowed | ||
| * to change the validation outcome (hence returing true from interopret()) | ||
| * and for our purposes of testing, this is sufficient. | ||
| */ | ||
| annotation: (discriminator) => { | ||
| return discriminator; | ||
| }, | ||
| }); | ||
|
|
||
| addKeyword({ | ||
| id: "https://spec.openapis.org/oas/schema/vocab/keyword/example", | ||
| interpret: (example, instance, context) => { | ||
| return true; | ||
| }, | ||
| annotation: (example) => { | ||
| return example; | ||
| }, | ||
| }); | ||
|
|
||
| addKeyword({ | ||
| id: "https://spec.openapis.org/oas/schema/vocab/keyword/externalDocs", | ||
| interpret: (externalDocs, instance, context) => { | ||
| return true; | ||
| }, | ||
| annotation: (externalDocs) => { | ||
| return externalDocs; | ||
| }, | ||
| }); | ||
|
|
||
| addKeyword({ | ||
| id: "https://spec.openapis.org/oas/schema/vocab/keyword/xml", | ||
| interpret: (xml, instance, context) => { | ||
| return true; | ||
| }, | ||
| annotation: (xml) => { | ||
| return xml; | ||
| }, | ||
| }); | ||
|
|
||
| defineVocabulary( | ||
| "https://spec.openapis.org/oas/3.1/vocab/base", | ||
| { | ||
| "discriminator": "https://spec.openapis.org/oas/schema/vocab/keyword/discriminator", | ||
| "example": "https://spec.openapis.org/oas/schema/vocab/keyword/example", | ||
| "externalDocs": "https://spec.openapis.org/oas/schema/vocab/keyword/externalDocs", | ||
| "xml": "https://spec.openapis.org/oas/schema/vocab/keyword/xml", | ||
| }, | ||
| ); |
There was a problem hiding this comment.
You shouldn't need to define the vocabulary or keywords. They're already loaded when you import from @hyperjump/json-schema/openapi-3-1.
There was a problem hiding this comment.
@jdesrosiers thanks for commenting- the problem is that we're using a schema with a different $id from the published 3.1 schema, as we're testing the in-development branches. Also I was mostly trying to get something else unblocked so I didn't dig as deeply as I might have otherwise.
There was a problem hiding this comment.
the problem is that we're using a schema with a different
$idfrom the published 3.1 schema
Right. Registering the meta-schemas immediately after this block addresses that concern. It's just defining the vocabulary (defineVocabulary) and the keywords (addKeyword) that's unnecessary.
There was a problem hiding this comment.
It's just defining the vocabulary (
defineVocabulary) and the keywords (addKeyword) that's unnecessary.
Apparently we still need defineVocabulary: just registering the meta-schemas results in
Error: Unrecognized vocabulary: https://spec.openapis.org/oas/3.2/vocab/base.
You can define this vocabulary with the 'defineVocabulary' function.
when validating 3.2 OpenAPI descriptions.
I expected that registering meta.yaml - whose title and description claim that it defines the OAS Base Vocabulary - would actually define the vocabulary 😞
There was a problem hiding this comment.
Oh, yeah. I never added support for 3.2. I'll work on it.
There shouldn't be any reason why you can't run the fail tests as well. You're throwing an error when a test fails, but for the purpose of test coverage, we shouldn't care whether the test passes or fails. You could just remove that check and run both sets of tests. |
[NOTE: The schema coverage will fail because the script is not smart enough to figure out that this branch derives from
dev.]This script confused me greatly when trying to fix the coverage, as it looks like the test script that runs. But it is not, the tests run out of the scripts/ directory.Apparently this is needed, so update it to use the correct schema.