Files
plane/apps/api
Manish Gupta 53ead0a2d1 [WEB-8374] test: assert preference payload and persistence, not just 200
The two positive controls only checked the status code, so they would still
pass if GET served another member's row or PATCH were a no-op.

- read: seed a known `preferences` value and assert it (plus `member_id`) comes
  back, instead of trusting the 200 alone.
- modify: assert the response payload, then `refresh_from_db()` and assert
  `pinned` actually persisted.
- also pin `validate_preferences`' merge semantics — the untouched default keys
  must survive a partial write, guarding a wholesale-replace regression.

Fail-before verified: a no-op PATCH fails the persistence assertion
(KeyError: 'pinned'), and a GET that serves a different member fails the
payload assertion. 4/4 pass on the real code.

Addresses CodeRabbit review on #9474.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-31 17:10:50 +05:30
..