Что проверять в ответе метода get user, обязательные и необязательные поля

Что проверяют

Опираетесь ли вы на контракт или на то, что сегодня отдаёт стенд. По ответу видно, различаете ли вы отсутствующее поле, null и пустую строку, и понимаете ли, что обязательность это свойство схемы, а не привычка.

Как отвечать

Начните с источника правды: спецификация метода говорит, какие поля обязательные. Проверка строится слоями: код состояния и тип содержимого, разбор тела и валидация по модели, затем смысловые утверждения.

class User(BaseModel):
    id: int
    email: EmailStr
    is_active: bool
    phone: str | None = None

def test_get_user(api, created_user):
    resp = api.get(f"/users/{created_user.id}")
    assert resp.status_code == 200
    user = User.model_validate(resp.json())
    assert user.id == created_user.id

Модель сама описывает обязательность: поле без значения по умолчанию требуется, поле со значением по умолчанию нет. Обязательные проверяются на присутствие, тип и осмысленность: идентификатор совпадает с запрошенным, почта проходит формат, признак активности именно булев. Необязательные проверяются иначе: прогон зелёный и когда поля нет, и когда оно пришло пустым, оба случая закрываются своими данными.

Добавьте про лишнее: в ответе не должно быть хеша пароля и служебных токенов, а состав полей может отличаться для владельца профиля и постороннего. И про отрицательные случаи: несуществующий пользователь отдаёт 404 с описанным телом ошибки, а не 200 с пустым объектом.

Где спотыкаются

Проверяют истинность вместо типа. Утверждение о том, что признак активности непустой, пройдёт и на строке, и на единице, и на словаре, а обращение по отсутствующему ключу падает с KeyError вместо понятного сообщения.

Второе: требуют необязательное поле. Тест ждёт телефон, первый же пользователь без телефона красит прогон, и проверку молча выключают. Обратная сторона: data.get("phone") возвращает None и когда ключа нет, и когда пришло значение null, а это разные ситуации.

Третье: прибивают ожидания к данным стенда: конкретное имя, конкретный идентификатор, порядок ролей. Такой тест живёт до первой чистки базы. Пользователя создаёт сам тест, а проверяются инварианты, а не содержимое чужой записи.