Settings test cases, for the save that did not happen

A settings screen is a promise that what the user typed is now true, and the fastest way to break that promise is a success message the server did not earn. Optimistic interfaces make this the default failure: the value updates locally, the request fails or partially fails, and nothing corrects the display. The user leaves believing a notification preference is off, a timezone is set or a visibility flag is private, and behaves accordingly. Testing it means forcing a single field to fail server side and checking that the interface says which one, rather than reporting the whole form as saved.

The security cases on this screen are disproportionate to how mundane it looks. A profile update endpoint that accepts a role, plan or verified flag from the client is a privilege escalation wearing an ordinary form. Changing email or password without re-authentication turns any unattended session into an account takeover. And a password change that does not invalidate other sessions fails at precisely the moment it is needed, because the user is usually changing it in response to a suspected compromise.

Free text on a profile is rendered by other people, which makes it an output encoding problem rather than an input validation one. A display name containing markup will often be escaped correctly on the profile page and rendered raw in a mention, an admin view, an export or an email, because encoding was applied where the value was entered rather than everywhere it appears. The avatar is the same shape of problem in binary form: accepted on extension rather than content, and served from the application origin where an SVG can execute.

Finally, the settings that look cosmetic have reach. A timezone change has to move timestamps without moving calendar dates such as a birthday, and it has to reach scheduled items by a documented rule rather than shifting them unexpectedly. A locale change has to reach notifications, exports and generated documents, not only the interface. And a visibility flag has to remove the field from the response payload rather than merely hiding it, because a value that is present but not displayed is still readable.