Schema validation basics in Postman - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the result of this Postman test script?

Given this Postman test script validating a JSON response schema, what will be the test result?

Postman

pm.test('Validate user schema', function () {
    const schema = {
        type: 'object',
        properties: {
            id: { type: 'integer' },
            name: { type: 'string' },
            email: { type: 'string', format: 'email' }
        },
        required: ['id', 'name', 'email']
    };
    pm.response.to.have.jsonSchema(schema);
});

A Test passes if response JSON has integer id, string name, and valid email string

B Test fails if response JSON has any extra properties beyond id, name, and email

C Test passes even if email is missing from response JSON

D Test fails if id is a string instead of integer

💡 Hint

Check what the required array means and how jsonSchema validates types.

The schema requires id, name, and email properties with specified types. The test passes only if all are present and valid. Extra properties do not cause failure by default.

❓ assertion

intermediate

Which assertion correctly validates a JSON array schema in Postman?

You want to validate that the response is an array of objects, each with a required id (integer) and optional name (string). Which assertion is correct?

A pm.response.to.have.jsonSchema({ type: 'array', items: { type: 'object', properties: { id: { type: 'string' }, name: { type: 'string' } }, required: ['id'] } });

B pm.response.to.have.jsonSchema({ type: 'array', items: { type: 'object', properties: { id: { type: 'integer' }, name: { type: 'string' } }, required: ['id'] } });

C pm.response.to.have.jsonSchema({ type: 'array', properties: { id: { type: 'integer' }, name: { type: 'string' } }, required: ['id'] });

D pm.response.to.have.jsonSchema({ type: 'object', properties: { id: { type: 'integer' }, name: { type: 'string' } }, required: ['id'] });

💡 Hint

Remember the difference between type: 'array' and type: 'object' and where items is used.

Option B correctly defines a schema for an array where each item is an object with required integer id and optional string name. Option B is for a single object, not an array. Option B misuses properties at array level. Option B wrongly expects id as string.

🔧 Debug

advanced

Why does this Postman schema validation test fail?

Examine the test script below. The response JSON is {"id": 5, "name": "Alice"}. Why does the test fail?

Postman

pm.test('Validate user schema', function () {
    const schema = {
        type: 'object',
        properties: {
            id: { type: 'integer' },
            name: { type: 'string' },
            email: { type: 'string', format: 'email' }
        },
        required: ['id', 'name', 'email']
    };
    pm.response.to.have.jsonSchema(schema);
});

A The schema has syntax errors causing failure

B The 'id' property is not an integer

C The 'name' property is not a string

D The response is missing the required 'email' property

💡 Hint

Check the required properties and compare with the response JSON.

The schema requires 'email' property, but the response JSON does not have it. This causes the validation to fail.

🧠 Conceptual

advanced

What does the 'additionalProperties: false' option do in JSON schema validation?

In a Postman JSON schema, what is the effect of setting additionalProperties: false inside an object schema?

A It makes all properties optional regardless of the 'required' list

B It allows any extra properties beyond those listed in 'properties' without failing validation

C It causes the validation to fail if the response JSON contains any properties not listed in 'properties'

D It disables all schema validation for that object

💡 Hint

Think about how strict the schema is about unexpected properties.

Setting additionalProperties: false means the JSON must not have any properties other than those explicitly defined in properties. Extra properties cause validation failure.

❓ framework

expert

How to write a Postman test to validate nested JSON schema with arrays and objects?

You receive a JSON response with this structure:

{
  "user": {
    "id": 10,
    "roles": ["admin", "editor"]
  }
}

Which Postman test script correctly validates that user is an object with integer id and an array roles of strings?

A

pm.test('Validate nested schema', () => {
  const schema = {
    type: 'object',
    properties: {
      user: {
        type: 'object',
        properties: {
          id: { type: 'integer' },
          roles: { type: 'array', items: { type: 'string' } }
        },
        required: ['id', 'roles']
      }
    },
    required: ['user']
  };
  pm.response.to.have.jsonSchema(schema);
});

B

pm.test('Validate nested schema', () => {
  const schema = {
    type: 'object',
    properties: {
      user: {
        type: 'array',
        items: { type: 'string' }
      }
    },
    required: ['user']
  };
  pm.response.to.have.jsonSchema(schema);
});

C

pm.test('Validate nested schema', () => {
  const schema = {
    type: 'object',
    properties: {
      id: { type: 'integer' },
      roles: { type: 'array', items: { type: 'string' } }
    },
    required: ['id', 'roles']
  };
  pm.response.to.have.jsonSchema(schema);
});

D

pm.test('Validate nested schema', () => {
  const schema = {
    type: 'object',
    properties: {
      user: {
        type: 'object',
        properties: {
          id: { type: 'string' },
          roles: { type: 'array', items: { type: 'integer' } }
        },
        required: ['id', 'roles']
      }
    },
    required: ['user']
  };
  pm.response.to.have.jsonSchema(schema);
});

💡 Hint

Focus on the nested user object and the types inside it.

Option A correctly defines user as an object with required integer id and array of strings roles. Option A wrongly treats user as an array. Option A misses the user nesting. Option A has wrong types for id and roles.

Practice

1. What is the main purpose of schema validation in Postman?

easy

A. To check if the server is online

B. To measure the response time of an API

C. To verify the API endpoint URL is correct

D. To check if the response data matches the expected structure and data types

Solution

1. Step 1: Understand schema validation concept

   Schema validation ensures the response data structure and types match what is expected.

2. Step 2: Compare options with schema validation purpose

   Only To check if the response data matches the expected structure and data types describes checking data structure and types, which is the core of schema validation.

3. Final Answer:

   To check if the response data matches the expected structure and data types -> Option D

4. Quick Check:

   Schema validation = check structure and types [OK]

Hint: Schema validation checks data shape and types [OK]

Common Mistakes:

• Confusing schema validation with performance testing
• Thinking schema validation checks URL correctness
• Assuming schema validation checks server status

2. Which Postman assertion syntax correctly validates a JSON response against a schema stored in schema variable?

easy

A. pm.response.to.have.jsonSchema(schema);

B. pm.response.to.have.schemaJson(schema);

C. pm.response.has.jsonSchema(schema);

D. pm.response.to.have.jsonSchemaCheck(schema);

Solution

1. Step 1: Recall correct Postman syntax for schema validation

   The correct method is pm.response.to.have.jsonSchema(schema); to validate JSON schema.

2. Step 2: Check each option for syntax correctness

   Only pm.response.to.have.jsonSchema(schema); matches the exact Postman syntax; others are invalid method names.

3. Final Answer:

   pm.response.to.have.jsonSchema(schema); -> Option A

4. Quick Check:

   Correct method = jsonSchema() [OK]

Hint: Use pm.response.to.have.jsonSchema(schema) exactly [OK]

Common Mistakes:

• Using incorrect method names like jsonSchemaCheck
• Mixing up method chaining order
• Omitting 'to.have' in the assertion

3. Given this schema snippet in Postman test script:

{
  "type": "object",
  "properties": {
    "id": {"type": "integer"},
    "name": {"type": "string"}
  },
  "required": ["id", "name"]
}

What will happen if the API response is {"id": 10, "name": "Alice"}?

medium

A. The schema validation will fail because 'id' is not a string

B. The schema validation will pass successfully

C. The schema validation will fail because 'name' is missing

D. The schema validation will fail due to missing required fields

Solution

1. Step 1: Analyze the schema requirements

   The schema expects an object with 'id' as integer and 'name' as string, both required.

2. Step 2: Compare the response with schema

   The response has 'id' as 10 (integer) and 'name' as "Alice" (string), satisfying all requirements.

3. Final Answer:

   The schema validation will pass successfully -> Option B

4. Quick Check:

   Response matches schema types and required fields [OK]

Hint: Match response types exactly to schema required fields [OK]

Common Mistakes:

• Confusing integer with string type
• Assuming missing fields when all are present
• Ignoring required fields in schema

4. You wrote this Postman test to validate a response schema:

const schema = {
  type: "object",
  properties: {
    age: { type: "integer" }
  },
  required: ["age"]
};
pm.test("Schema is valid");
pm.response.to.have.jsonSchema(schema);

But the test always fails even when the response has an integer age. What is the likely error?

medium

A. The assertion should be inside pm.test callback, but the code uses pm.test incorrectly

B. The test function is named pm.test but should be pm.response.test

C. Using pm.test instead of pm.response.to.have.jsonSchema

D. The assertion is inside pm.test but the function name is misspelled as pm.test

Solution

1. Step 1: Check the test function usage

   The correct syntax is pm.test("name", () => { assertion }); but the code calls pm.test("Schema is valid"); without the required callback function.

2. Step 2: Check assertion placement

   The assertion pm.response.to.have.jsonSchema(schema); is outside the pm.test callback and will not be properly associated with the test.

3. Final Answer:

   The assertion should be inside pm.test callback, but the code uses pm.test incorrectly -> Option A

4. Quick Check:

   pm.test requires callback containing assertion [OK]

Hint: Always wrap assertions in pm.test("name", () => { ... }) [OK]

Common Mistakes:

• Calling assertions directly without pm.test wrapper
• Misspelling pm.test or using wrong test function
• Not wrapping assertion inside pm.test callback

5. You want to validate an API response that returns a list of user objects, each with id (integer) and optional email (string). Which JSON schema correctly validates this response array?

hard

A. {
"type": "array",
"properties": {
"id": {"type": "integer"},
"email": {"type": "string"}
},
"required": ["id"]
}

B. {
"type": "object",
"properties": {
"id": {"type": "integer"},
"email": {"type": "string"}
},
"required": ["id"]
}

C. {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": {"type": "integer"},
"email": {"type": "string"}
},
"required": ["id"]
}
}

D. {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": {"type": "string"},
"email": {"type": "string"}
},
"required": ["id", "email"]
}
}

Solution

1. Step 1: Identify the response type

   The response is an array of user objects, so schema type must be "array" with "items" describing each object.

2. Step 2: Check object properties and requirements

   Each object must have "id" as integer (required) and "email" as optional string (not required).

3. Step 3: Validate options against requirements

   { "type": "array", "items": { "type": "object", "properties": { "id": {"type": "integer"}, "email": {"type": "string"} }, "required": ["id"] } } correctly defines an array with items as objects, "id" integer required, "email" string optional. Others either define object instead of array, wrong types, or require "email".

4. Final Answer:

   { "type": "array", "items": { "type": "object", "properties": { "id": {"type": "integer"}, "email": {"type": "string"} }, "required": ["id"] } } -> Option C

5. Quick Check:

   Array of objects with required id integer and optional email string [OK]

Hint: Use "type": "array" with "items" for object schema [OK]

Common Mistakes:

• Defining response as object instead of array
• Marking optional fields as required
• Using wrong data types for properties