Question 1

How do you work with JSON in an API test — where does parsing happen?

Accepted Answer

With Playwright's request fixture I take the response as an object via await response.json() — JSON.parse is never called by hand. When sending a request, the data: parameter serialises the object automatically. Manual JSON.parse is only needed for raw text: a fixture read from a file, an environment variable, or a raw body from response.text(). An important detail: response.json() throws when the response is not JSON, so checking the status code and content-type first pays off — otherwise an HTML error page from the server shows up as a cryptic parse error.

Question 2

Why is JSON.parse(JSON.stringify(obj)) a poor choice for a deep copy?

Accepted Answer

Because it is not a copy but a lossy simplification: undefined fields and functions vanish, Date becomes a string, NaN/Infinity become null, Map/Set collapse into empty objects, and a circular reference throws outright. In test code the consequences are nasty: toEqual produces a confusing diff or a wrong test "passes". The alternatives: structuredClone(obj) — modern and correct; a factory function — the best option for test data, since each call builds a fresh object and nothing is shared.

Question 3

How do you assert an API response — exact values or structure?

Accepted Answer

I split it into two levels. The structure/contract level is in every test: field presence, types, whether something is an array, enum values within an allowed set. These checks survive data changes but fail immediately when the contract breaks. Exact value checks I apply only to data the test itself created — e.g. an order created by POST coming back from GET with the same total. The most common mistake is asserting exact values against incidental data in the stage database — such a test turns red on its own a week later.

Question 4

How would you organise schema validation in a large API suite?

Accepted Answer

Hand-written expect.objectContaining checks work up to 5-10 endpoints, after which duplication and drift set in. The scalable answer: keep schemas in one place and validate with a schema library (zod, ajv, etc.) — one schema per endpoint, one line in the test. The advantages: (1) the schema is both documentation and validation; (2) the TypeScript type can be inferred from the schema, so the type and the runtime check share one source; (3) if the backend has an OpenAPI spec, schemas can be generated from it and drift caught automatically. State the limits too: schema validation does not replace business-logic assertions — it only confirms the shape; and an overly strict schema (no additional properties) can fail needlessly when the backend makes an additive change, so that call should be agreed with the team.

Input value	After JSON.stringify	Consequence
an undefined field	the field disappears entirely	the difference between "absent" and "empty" is erased
a Date object	an ISO string	parsing back gives a string, not a Date
a function / method	dropped	a class instance degrades to a plain object
NaN, Infinity	null	a calculation error gets hidden
Map, Set	an empty object {}	the data is silently lost
a circular reference	throws a TypeError	hit when logging an object

Working with JSON and data

📚 Sources and documentation