Это отрывок из статьи Как тестировать методы REST API. Мне хочется, чтобы было возможность дать ссылку именно на тестирование заголовков)
Заголовки должны где-то обрабатываться:
— на сервере;
— на клиенте;
Иначе они не нужны, только лишний трафик гонять. Мы ведь передаем сообщение по сети, если интернет плохой, то каждый байт на счету. Зачем отправлять информацию, которую никто не использует?
Так что разработчики используют «Принцип меньшего зла»: заголовок или кем-то обрабатывается, или он вообще не нужен.
Если заголовка нет:
— используется дефолтный, прописанный в коде;
— он вообще не нужен;
Язык должен указываться всегда, иначе непонятно, как вернуть ответ от сервера. Но разработчик может в код зашить русский язык, и тогда даже если вы передадите заголовок «Accept-Language: en-US», то ответ получите на русском.
Почему? Потому что разработчик игнорирует этот заголовок, он его не считывает из запроса в принципе. Его право =)
Возможные ситуации, которые надо проверить
Заголовок не передан, как система реагирует:
— выдает ошибку → понятно ли, что мне надо сделать?
— применяет поведение по умолчанию (если язык не передан, используй русский)
Заголовок передан:
— верно
— неверно → какая ошибка?
Плюс регистрозависимость. Согласно спецификации, все заголовки должны быть регистронезависимы. И неважно, как я их передаю. Могу в CamelCase (первая буква большая, остальные мелкие), могу в верхнем регистре, причем как значение заголовка, так и его название, могу как-то ещё:
Accept: application/json
Accept: APPLICATION/JSON
ACCEPT: application/json
ACCEPT: APPLICATION/JSON
ACcePT: APPlicATIon/JSon
Проверить эти варианты — очень важно. Потому что за регистронезависимость отвечает разработчик, сама по себе из воздуха она не появится. Он должен прописать это в коде.
Был случай у моих коллег — заголовок проверили, всё работает. Но проверили по доке, прислали значения «как указано». Вот Accept может быть (как передаются входные данные):
- application/json
application/xml
А потом пользователи приходят и жалуются на ошибки «у вас плохой заголовок». При том, что заголовок они отправили правильный. Начали разбираться — запрос идет не напрямую на сервер, он проходит через прокси Nginx. А Nginx меняет заголовки на upper case: ACCEPT: APPLICATION/JSON.
Система к такому не готова, она ищет «Accept», не находит его и выдает ошибку. А переданный заголовок игнорирует. Так что проверять регистр — надо!
Итого — тестирование заголовков в API
Заголовки из документации работают (в целом)
А если какой-то не передать? (обязательность)
А если передать, но неправильно? (текст ошибки)
Позитивные тесты по доке
Регистронезависимость заголовков
Практика на примере Users
В документации вообще ничего не сказано про заголовки. Поэтому проверяем, можно ли отправить сообщение без них. Идем на вкладку Headers и снимаем все галки, если они по каким-то причинам там стояли. Запрос сработал успешно:
Но обратите внимание, что в постмане есть ещё скрытые заголовки (hidden):
Это те заголовки, что генерирует сам постман. По сути постман — это клиент, помогающий нам отправить запрос на сервер. И у него есть какие-то свои фишечки, ограничения, заголовки опять же.
Можно нажать на это сообщение “(цифра) hidden” и раскрыть этот список (а потом всегда можно нажать на кнопку “hide hidden”:
Это некий стандарт, дефолтные значения по умолчанию. Тот же Cache-Control, раз вы его не передаете, по факту он вам не нужен, то есть как если бы вы указали “no-cache”.
Но учтите, что если снять тут все-все-все галки, система может выдать ошибку:
Плохо ли это? Стоит ли заводить баг “в документации сказано, что можно без заголовков, а так не работает” — нет. Для начала попробуйте отправить запрос через curl и посмотрите на результат.
Помните, что Postman — это всё-таки клиент, у которого есть свои навороты. Так что пусть он их накручивает сколько влезет, эти хидден-заголовки тестировать особо не надо. А вот послать хотя бы разок честный curl — надо!
Так что прячем hidden-заголовки и проверяем без них в этом пункте. Да, doregister без заголовков работает, всё ок.
См также:
Как тестировать методы REST API — полная статья, не только про заголовки
PS — статья написана в помощь студентам моих курсов «Инженер по тестированию ПО» и «Тестирование REST API». Хотите практики? Приходите к нам =)
Комментариев нет:
Отправить комментарий