🟩 I2 · expect(response).toBeOK() and JSON Assertion
I2 · expect(response).toBeOK() and JSON: `expect(response).toBeOK()` is a SHORTCUT Playwright wrote for checking a 2xx status — the TypeScript translation of H1's `.statusCode(20
`expect(response).toBeOK()` is a SHORTCUT Playwright wrote for checking a 2xx status — the TypeScript translation of H1's `.statusCode(200)`, but checking the ENTIRE 2xx range (200-299) instead of a single code. To verify the JSON body, you parse it with `await response.json()` and use normal Playwright `expect(...)` assertions (`toBe`, `toEqual`, `toContain`) — the SAME `expect` API you use writing `expect(locator).toBeVisible()` in UI tests, only the object is a piece of data instead of a DOM element. Why does this consistency matter? Because GROUP I's power (I3) lies in making API and UI assertions WRITTEN with the SAME syntax — there is NO context-switching burden in the tester's mind between "API mode" and "UI mode". **For a deep Playwright assertion guide → see the `/playwright` page.**
🎬 The Same expect(), Two Different Objects
expect(locator).toBeVisible()
expect(body.title).toBe(...)
In a UI test you write `expect(locator).toBeVisible()` — verifying a DOM element.
In an API test you write `expect(body.title).toBe(...)` — the SAME `expect` function, a different object.
The lesson — the mental model is the SAME; only what you check (DOM or JSON) changes. This is the FOUNDATION of the hybrid tests in I3.
The Order for Verifying Status and Body
Verify the 2xx range with expect(response.ok()).toBeTruthy() or toBeOK().
Convert the raw JSON to a JavaScript object with await response.json().
Check the content with expect(body.field).toBe(...)/toContain(...).
Order the steps for verifying a Playwright API response.