Session 4: API Testing | Postman | API Response Validations | Different types of Assertions

Summary of Technological Concepts & Postman API Testing (Session 4)

Core idea: Validate the API response using Postman assertions

This session builds on prior knowledge of JSON and JSONPath for locating specific nodes in an API response. It emphasizes that you must first understand what your API response looks like—status code, headers, cookies, response time, and body—before writing validations.

---

What to validate in an API response (5 main components)

1. Status code
2. Headers (especially static headers like Content-Type)
3. Cookies (presence and expected values)
4. Response time (assert within a threshold)
5. Response body (data validation using JSONPath + JSON schema validation)

---

Postman assertions & libraries used

• Assertions are validation points defined inside Postman’s Tests tab.
• Uses Postman’s built-in pm (Postman) library:
  • Assertion functions are implemented in JavaScript (you don’t need advanced JS, but you must use pm.* functions).
• Uses Chai assertion semantics (e.g., pm.test / pm.expect style).
• For JSON schema validation, uses tv4 (Tiny Validator v4).

---

Writing assertions in Postman

Assertions are placed in the Tests tab per request. Two JavaScript styles are typically shown for pm.test():

1. Normal function
2. Arrow function (most popular)

---

Response validation details

1) Status code assertions

Examples described:

• Exact match:
  • pm.response.to.have.status(200)
• Multiple accepted statuses:
  • pm.expect(pm.response.code).to.be.oneOf([201, 202])
• Also includes validating status-related messages (e.g., POST may return “Created” with 201) as part of status validation.

A GET request example is used to show tests passing/failing depending on whether the expected status matches the actual response.

---

2) Headers validation

Key focus: validate static headers, especially Content-Type (dynamic headers are not reliable).

Two header-related checks:

1. Header presence (e.g., confirming Content-Type exists)
2. Header value match (e.g., expecting application/json; charset=utf-8 as a specific target value)

The session notes that some header fields are dynamic (e.g., connection/caching-related headers), so validations should target predictable ones.

---

3) Cookies validation

Two types of checks:

1. Cookie presence
   • Example concept: pm.cookies.has('language')
2. Cookie value
   • Example concept: pm.cookies.get('language') === 'en_US_GB'

Cookie validations pass or fail based on the expected cookie values.

---

4) Response time validation

Because response time varies, validations should be threshold-based rather than exact milliseconds.

Example concept:

• pm.expect(pm.response.responseTime).to.be.below(50)

Tests pass if response time is below the chosen limit; they fail otherwise. Alternatives like checking above/below ranges may be discussed, but range checks are not always feasible.

---

Response body validation (most important part)

Response body validation depends on the request type; for GET requests, emphasis is placed on deeper body and schema validation.

Common preparation step: capture JSON body

Before body assertions, store the response JSON into a variable:

• let jsonData = pm.response.json();

This value can be reused across multiple tests.

---

Body validation type 1: Validate value/data types

Purpose: confirm fields have the correct JSON data types, such as:

• id → number
• name → string
• courses → array
• the overall response → object

Uses:

• pm.expect(jsonData.<path>).to.be.an('string'/'number'/'array')

The session demonstrates failures by intentionally swapping expected types.

---

Body validation type 2: Validate array properties/contents

Purpose: confirm an array contains specific values.

Two approaches:

1. Single value inclusion
   • pm.expect(jsonData.courses).to.include('Java')
2. Multiple values inclusion (order not important)
   • use something like to.have.members([ ... ])

Failure occurs if an expected element is missing from the array.

---

Body validation type 3: Validate specific JSON field values

Purpose: verify exact expected values for fields such as:

• id, name, location, phone
• values inside the courses array

Uses JSONPath to target exact nodes, including array indexes (e.g., courses[0], courses[1]).

Important rule emphasized:

• If multiple assertions are included in a single pm.test, one failure fails the entire test.

For complex JSON or multiple records, correct JSONPath generation is critical.

---

Body validation type 4: JSON schema validation (tv4)

Purpose: validate that the entire response matches a predefined JSON schema (structure + data types + required fields).

Conceptual meaning of schema:

• Like a database table schema: it defines which fields exist and what types they must be.
• If the response doesn’t follow the schema, validation fails.

How schema is obtained:

• Use external tools to generate JSON schema from sample JSON.
• Store the schema as a variable in tests, then validate the response JSON against it.

Implementation concept:

• tv4.validate(jsonData, schema) returns true/false
• assertions expect the result to be true

A demonstration includes intentionally breaking schema expectations to show failing validation.

---

Running validation across a collection

Instead of running each request individually, the session recommends:

• Use Postman Run collection (from the three-dot menu)
• Execute requests sequentially in one run
• Verify overall pass/fail across operations such as:
  • get single student
  • get all students
  • create
  • update
  • delete

It states that for non-GET requests, validation focuses more on status code, headers, cookies, and response time, while GET requests require deeper response body + schema validation.

---

Main speakers / sources

• Speaker: Instructor (unnamed), teaching Postman API testing concepts using auto-generated subtitles.
• Primary source/library referenced:
  • Postman pm library
  • Chai-style assertions via Postman
  • tv4 (Tiny Validator v4) for JSON schema validation.