Да, если по спецификации поле должно быть строкой, а backend отдаёт другой тип — это, конечно, уже вопрос соответствия контракту. И если null там вообще не предусмотрен, то логичнее исправить backend, а не заставлять frontend гадать, что с этим делать.

Но смысл моего примера немного в другом: при тестировании мы всё-таки смотрим не только на happy path, а стараемся держать в голове возможные варианты поведения системы. Пользователь ведь не всегда действует так, как мы задумали. Кто-то может отправить запрос напрямую через Postman, подставить null, пустую строку, 0, вообще убрать поле или передать неожидаемое значение.

И вот такие варианты тоже полезно проверять — не потому, что все они обязательно должны быть валидными, а чтобы понять, как система на них реагирует: корректно отклоняет, возвращает понятную ошибку или внезапно ломается.

Согласен на все 💯 ! Действительно моя вина - думал в направлении тепличной разработки. Но не подумал о прямых запросах апи. Признаю

Смотреть на это как на разные состояния данных, а не просто на «пустое значение». При тестировании стоит проверить каждый вариант отдельно: поле отсутствует, null, пустая строка, 0, false — и посмотреть, как API и интерфейс обрабатывают каждый из них. А дальше уже сверять поведение с требованиями: что именно должно происходить в каждом случае.

А вообще я публикую такие статьи скорее как интересные наблюдения и рабочие моменты, которые сам подмечал в процессе работы. Иногда какая-то вроде бы мелочь оказывается интересной, если посмотреть на неё чуть внимательнее. Вот такими наблюдениями и хочется делиться с остальными.

И если разные, то предлагается менять код чтобы были совпадения? Или задача тогда попадет под несрочный статус, как незначительное…?

Не обязательно менять код только потому, что состояния разные. 🙂 Тут всё упирается в требования и ожидаемое поведение.

Если по требованиям avatar: null — нормальный вариант, то ничего исправлять не нужно. Если же frontend ожидает строку и из-за null падает или работает некорректно — тогда уже заводим баг.

И приоритет тоже определяется не самим null или отсутствием поля, а последствиями для пользователя и системы. Поэтому одна и та же ситуация в разных проектах вполне может иметь разную серьёзность.