Всем доброго дня! Я Святослав Ященко, работаю в СберТехе, лидирую команду QA Platform V Kintsugi — это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Развивается вместе с СУБД Pangolin — целевой в Сбере и не только.

У нашего продукта микросервисная архитектура и Web UI. Часто при тестировании фронтенда я имею дело с ещё не дописанной функциональностью API, или же с ситуациями, когда в контракте API есть расхождения с ожиданиями фронтенда.

Хорошо, когда можно заносить моки в окружение или использовать снифферы с возможностью подмены трафика. Но, по разным причинам, не всегда бывает такая возможность. Что остаётся? Ждать, пока разработчик приведёт API в порядок? Но ведь фронтенд-часть готова уже сейчас и ждёт своего тестировщика...

Решение нашлось под рукой — в моём браузере Chrome. Если вы пользуетесь Chrome, то, вероятно, открываете DevTools. Чаще всего нам хватает вкладок Elements, Console, Network и Application. Но так ли прост DevTools? С этой статьи я начинаю цикл коротких руководств, посвящённых скрытым, но крайне полезным фичам Chrome. И начну с подмены входящего трафика.

Итак, вы тестируете фронтенд с пока не дописанным API. Вкратце разберу возможные решения в этом случае, и пойдём дальше. 

1. Моки. Идеально, если можно занести мок в ваше окружение. Мок пригодится в различных ситуациях — от ручного тестирования и автоматизации регресса до нагрузки. Но если возможности нет (например, отдел безопасности видит в этом серьёзную уязвимость), то вариант отпадает.

2. Снифферы с возможностью подмены трафика. Если нужно быстро проверить гипотезу не на стандартном ответе API, то часто это самый быстрый вариант. Берём Charles Proxy (хватит триальной версии), настраиваем по инструкции — и вот мы уже ставим точки остановки на нужных end point-ах и подменяем нужные данные в ответе запроса. Только вот снифферы — не ваш вариант, если вы работаете под слоями VPN, и вдобавок установку сторонних приложений не приветствует тот же отдел безопасности.

3. Дождаться, пока разработчик допьёт кофе и приведёт API в порядок. Рано или поздно он это сделает. Но зачем ждать, если не терпится уже сейчас заняться багами?

Здесь на помощь приходит такая полезная фича Chrome-браузера, как подмена входящего трафика. Она называется Override incoming network requests и позволяет сохранять на локальном устройстве в виде файлов:

1. локальные переопределения контента ответа на запрос (и подменять приходящий в ответе контент на изменённый);

2. локальные переопределения заголовков ответа запроса (и подменять приходящие в ответе заголовки на изменённые). 

Для активации откройте DevTools и в правой части страницы нажмите на три точки. Из выпадающего списка выберите опцию Run command.

Откроется список команд и строка поиска. Введите в строку поиска «override network requests», после чего список команд сократится до одной — нас интересующей. 

Если команда называется Disable override network requests, то можно переходить к следующему шагу. А если ранее вы не занимались подменой трафика через Chrome, скорее всего, увидите название Enable override network requests. 

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

Теперь можно приступить к подмене входящего трафика. Для демонстрации я использую свой небольшой самописный сайт, сделанный давным-давно в рамках тестового задания для одной компании. Сайт предназначен для получения информации по карте по BIN-номеру. Если номер существует в базе, то вернётся найденная информация. Если номера нет — вернётся ошибка. При запросе сайт обращается к end point-у API /get-info. Перехват ответа на этот end point я и продемонстрирую.

Override content

Жму правой кнопкой мыши на HTTP-вызов get-info во вкладке Network. Выбираю из выпадающего списка опцию Override content.

Сразу после этого на вкладке DevTools возникает уведомление: Select a folder to store override files in. На этом шаге вы выбираете директорию на вашей машине, где будут храниться все переопределённые ответы на API-запросы. Я для себя завёл отдельную директорию Overrides и выбрал её.

После этого надо разрешить DevTools полный доступ к выбранному каталогу.

Повторно я нажимаю на вызов get-info на вкладке Requests, и меня наконец перенаправляет в раздел DevTools под названием Overrides.

Обратите внимание, в левой части располагается дерево директорий с переопределёнными файлами. Переопределение моего get-info попало в раздел с URL моего сайта. Все переопределённые ответы в рамках одного сайта будут располагаться в одной и той же директории.

В правой части открыт редактор тела контента моего запроса. Прописанный здесь текст, начиная с этого момента, будет подставляться вместо того, что приходит с сервера. Давайте его изменим: в поле Data -> Alpha_3 вместо USA пропишем FRANCE. 

Обязательно после внесения изменений сохраните их: комбинация клавиш Ctrl + S (Windows) / Cmd + S (Mac OS)! После этого мы повторно инициируем вызов get-info в интерфейсе.

Как видите, запрос get-info на вкладке Network получил небольшой фиолетовый кружок: знак, что серверное тело запроса было переопределено и взято тело запроса из локального окружения. В ответе мы теперь наблюдаем изменённое нами поле alpha_3 — FRANCE, и это же поле наблюдаем в UI-таблице.

Override headers

Фича позволяет перехватывать и подменять заголовки в ответе от сервера. Для чего это может понадобиться тестировщику? Допустим, backend, принимая и обрабатывая полученный от frontend запрос, добавляет свои заголовки, критично важные для функциональности. В наших силах подменить эти заголовки локальными и посмотреть, как поведёт себя frontend-часть.

Вновь инициирую появление запроса на вкладке Network, кликнув по нему правой кнопкой мыши. В появившемся выпадающем списке меня интересует опция Override headers.

Как только я выбрал эту опцию, в правой части окна заголовки запроса стали доступны для редактирования. И было инициировано создание пока что пустого файла .headers, куда лягут будущие переопределённые заголовки.

Вы также можете заметить кнопку «+ Add header» под самым нижним заголовком. Дело в том, что функциональность подмены заголовков позволяет не только заменять значение уже существующих заголовков, но и добавлять в заголовки ответа совершенно новые. Именно это позволит нам протестировать, к примеру, реакцию frontend-а на получение от API новых заголовков ещё до того, как передача этих заголовков будет реализована на backend.

Изменим значение заголовка Server c unicorn на random, а также добавим новый заголовок под названием Authorization и присвоим ему значение Bearer 123. Почему такой заголовок? Нередко токен авторизации передаётся именно в таком заголовке, и его значение часто имеет вид Bearer <некоторый токен>. Подобной подменой мы проверим реакцию приложения на некорректный токен авторизации.

Можно заметить, что изменённые и добавленные поля закрашены собственным цветом для удобства их обнаружения. Посмотрим, как изменения выглядят в файле .headers. Кликнем по ссылке .headers в правой части экрана по центру вкладки Headers.

Нас переносит на вкладку Overrides, где файл .headers уже открыт для редактирования. Синтаксис файла следующий:

• Apply to: get-info: изменения применяются только к этому end point-у.

• server: random: наше новое значение уже существующего заголовка. По непонятной причине название изменённого заголовка в файле пишется с маленькой буквы, хотя в запросе он будет фигурировать с заглавной.

• authorization: Bearer 123: новый заголовок со сгенерированным нами произвольным значением.

А что, если у меня десять end point-ов в API и в каждый я хочу добавить один и тот же новый заголовок с одним и тем же значением? Безусловно, можно добавить все десять end point-ов в этот же файл — нужно всего лишь десять раз нажать Add override rule и прописать заголовок. Но есть и способ проще: добавим лишь одно новое правило через Add override rule, но укажем Apply to: *. Такой синтаксис используют для применения нового заголовка всем end point-ам нашего приложения.

Давайте добавим новый заголовок Common со значением qwerty. И обязательно нажмём CMD+S (для macOS) / Ctrl + S (Для windows)  для применения изменений.

Теперь возвращаемся на вкладку Network и обновляем страницу. Приложение подгрузит JS- и CSS-файлы, заголовки одного из которых я попробую открыть. Я вижу, что у него добавился заголовок Common: qwerty, как и ожидалось, но только он один, все прочие остались без изменений.

Теперь я вновь инициирую вызов get-info и раскрою его. Здесь вижу изменения в заголовке Server, новый заголовок Authorization и общий для всех end point-ов приложения заголовок Common.

В заключение

Описанная мною функциональность крайне полезна, но, к сожалению, ограничена и не позволяет полностью заменить собою обычные снифферы. 

Преимущества:

• поставляется вместе с браузером;

• позволяет переопределять тело ответа от сервера;

• позволяет переопределять HTTP-заголовки в ответе сервера как для отдельных end point-ов, так и для всех разом через Apply to: *. И переопределять заголовки Websocket точно так же, как и HTTP (между прочим, нетривиальная задача для обычного сниффера)/

Недостатки:

• не позволяет переопределить тело и заголовки запроса;

• не позволяет подменять статус-код ответа;

• и не позволяет подменять Websocket-сообщения.

Вам решать, окажется ли инструмент полезным в вашей ситуации.

В следующей статье я собираюсь подробно рассказать о другой возможности DevTools — об измерении производительности вкладки браузера. Этот вид тестирования мы в команде используем ежедневно.

Напишите в комментариях, какие возможности DevTools вам было бы интересно разобрать? Если я работаю с этими инструментами, то включу их в цикл статей!

А чтобы не пропустить новые руководства, приходите в наше сообщество, там мы делимся разным полезным и публикуем вакансии.