Interview Corner

A: JSON Schema is a vocabulary for annotating and validating JSON documents. It defines the expected structure — field names, data types, required fields, and constraints. In API testing, it is important because it validates the entire response structure in a single assertion, catching issues like missing fields, type changes, and unexpected properties. Without schema validation, you are checking fields individually and can miss structural regressions that break consumers.

A: "integer" validates whole numbers only — 1, 42, -5 are valid but 1.5 is not. "number" validates any numeric value including decimals — 1, 42, 1.5, -5.7 are all valid. Use "integer" for IDs, counts, and quantities. Use "number" for prices, ratings, and measurements. This is a common source of schema validation failures when a backend change causes a field to return 100.0 instead of 100.

A: "additionalProperties": false rejects any field in the response that is not explicitly defined in the schema's "properties" section. I use it for strict contract testing where both producer and consumer must agree on the exact response structure. It catches cases where the API accidentally exposes internal fields like "internalId" or "debugInfo." However, it can break tests when the API team intentionally adds new fields. The decision to use it depends on the team — strict is better for contract testing, permissive is better for forward-compatible testing.

A: Use an array for the type: "type": ["string", "null"]. This allows the field to be either a string or null. For example, a "middleName" field that might not exist for all users would have "type": ["string", "null"]. Do not confuse nullable with optional — a field can be required AND nullable. "required" means the field must exist in the response. The type array controls what values it can have. So required + ["string", "null"] means the field must be present, but its value can be null.

A: Schema validation checks if an API response matches a predefined structure. It is a unilateral check — one side validates against a schema. Contract testing is bilateral — both the producer and consumer agree on a contract, and both sides validate against it. Schema validation is a form of contract testing, but contract testing tools like Pact go further. Pact records consumer expectations, sends them to the producer, and the producer verifies it can fulfill them. Schema validation catches structural drift. Contract testing catches behavioral mismatches too.

A: I add schema validation as a separate stage in the CI/CD pipeline, between unit tests and integration tests. For REST Assured, it is a Maven test execution targeting the SchemaValidationTest class. For Postman, it is a Newman run against the schema validation collection. The pipeline is configured to fail the build and send alerts if schema validation fails. I run it on every PR, after staging deployments, and as a nightly scheduled job for third-party APIs. Schema files are committed to version control alongside the test code, so changes are tracked and reviewed in PRs.

A: Status code checks only verify the API did not crash — a 200 does not mean the response is correct. Individual field checks verify specific values but miss structural changes. Imagine checking that "name" equals "Rahul" — this passes even if the API removed the "email" field, changed "age" from integer to string, or added an "internalDebugId" field. Schema validation catches ALL of these in one assertion. It is not a replacement for field checks — it is a complement. Field checks verify correctness. Schema validation verifies structure. You need both.