(nullable) Enum values not enforced on JSON schema validation

Hiā€™ Iā€™m stuck with the following issue:

I have an API field that is an enum, but it can also be null:
fruit enumā”ƒnull
Allowed: appleā”ƒorangeā”ƒpearā”ƒnull

I need to create a JSON schema validation for this field to account for all of the possible cases. Based on several posts I found, I resolved it like this:

"fruit": {
	"type": ["string", "null"],
	"enum": ["apple", "orange", "pear", null]
}

This format seems to please the Postman, so the validation passes and everything is great. However, the current solution is unable to raise an issue when an unknown value is found in the fruit field: if I was to replace apple ā†’ potato (the full set looking like this: [ā€œpotatoā€, ā€œorangeā€, ā€œpearā€, null]) and the ā€œappleā€ would be found in the response, the schema validation would still pass with no problems.

Iā€™ve tried using ā€œnullableā€ keyword, also specifying types as an array of ā€œanyOfā€, but still no luck. Itā€™s either an ā€œinvalid schemaā€ issue or faulty validation (not checking the actual values apart from null).

As for validating schema, I use the default validation method (if you can call it like that):
pm.response.to.have.jsonSchema(schema);

I have also marked this field as ā€œrequiredā€ in the schema description.

Thanks in advance for any advice!

  • Platform Details:
  • Version
    11.13.0
  • OS platform
    win32 10.0.22631

Enum is used to constrain a property to have a fixed set of values.

JSON is key\value pairs. Fruit is the property\key in your scenario.

const schema = {
    "type": "object",
    "properties": {
        "fruit": {
            "enum": ["apple", "orange", "pear", null]
        }
    }
}

let testData = ["apple", "orange", "pear", null, "peach"]

testData.forEach(element =>
    pm.test(`API response schema is valid: ${element}`, () => {
        let jsonData = { "fruit": element };
        pm.expect(jsonData).to.have.jsonSchema(schema);
    })
);

Hi, Mike! Appreciate your reply! You are correct - fruit really is a property in this scenario.
It was nice to learn that I donā€™t really need to specify the type - I removed the type declaration from my code.

However, the validation still doesnā€™t work in the correct way and Iā€™m all out of ideas. Inside the same JSON, I have another enum property - status - that is not nullable, meaning it only has string values. Among the possible values there are ā€œvalidā€ and ā€œexpiredā€. When I remove ā€œexpiredā€, nothing happens and the validation passes, even though there are objects with ā€œstatusā€: ā€œexpiredā€ present in the response. However, when I remove ā€œvalidā€, I get the validation error that the field contains illegal value (ā€œstatusā€: ā€œvalidā€ can also be found in the response).

As for the ā€œfruitā€, itā€™s still not validating anything apart from the null itself.
Itā€™s absolutely maddening and Iā€™m unable to find a pattern here.

You will need to share an example response with all of the required elements in.

Not sure what you mean about the fruit. Iā€™ve provided a working example of validating that field.

You can see that it passes for apple, orange, pear and null, but fails for peach.

If you are having issues, please provide your updated code.

I think I found the root of this issue and itā€™s a really dumb one. I realized this when I started going through my schema definition line by line. My schema begins with the following code:

const schema = {
    "type": "array",
    "items": [{
        "type": "object",
        "properties": {
            "id": {
                "type": "integer"
            },

When experimenting with another field, Postbot assistant suggested a fix that solved some formatting bugs in the whole file, including the code snippet provided above. So the correct way to define a schema is as follows:

const schema = {
    "type": "array",
    "items": {
        "type": "object",
        "properties": {
            "id": {
                "type": "integer"
            },

I violated the JSON format by adding array brackets while there was no need for that - the ā€œtypeā€ property already specifies that.
While it yielded no errors, it seemed to mess with the validation of some fields, including enums.
I think the issue is resolved now, sorry for wasting your time with such a silly problem and thanks for all the help!

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.