Aqua Den / Блог автотестировщика

Вкладка Network. Фронт обменивается данными с бэком. Логично, что эти самые данные должны где-то отображаться. Напомню, что при первом переходе на страницу и по мере её обработки происходит отправка запросов на получение конкретных данных (картинок, стилей и т.п.). Так вот, все эти данные отображаются в хронологическом (по умолчанию) порядке именно здесь. Здесь же отображаются и запросы к конкретным ручкам, которые выполняет фронт, когда с ним взаимодействует пользователь. Вот на этом мы и остановимся подробнее! Исследовать мы будем какой-нибудь рандомный сайт...

Попробуем представить, как же может быть устроен обмен данными между фронтом и сервисами. И начнём мы с каталога товаров. Чтобы представить всю картину целиком, начнём с самого начала: ты, как покупатель, заходишь в интернет-магазин через свой любимый браузер Амиго. Загружаются картиночки, скрипты, HTML-код; рисуются элементы... В этот момент начинает выполняться загруженный скрипт, который обращается к сервису каталога, чтобы получить список товаров (которые, между прочим, на текущий момент ещё не отрисованы). Допустим, у сервиса каталога будет всего одна ручка, назовём её products. Принимать она будет GET запрос, в теле которого мы будем задавать значение фильтра для товаров...

Здравствуй, мой юный автотестировщик! В прошлых частях нашего короткого чтива мы начали говорить про микросервисную архитектуру приложения на примере простого интернет-магазина. Кратко напомню суть: есть интернет-магазин с очень ограниченным функционалом - фронт, каталог товаров и оформление заказа. Каждый кусок функционала - сильный и независимый сервис со своей базой данных, который может работать автономно. Каждый сервис разрабатывает своя команда. Каждый сервис (на минуточку!) может быть написан на разных языках программирования. Взаимодействие с сервисами осуществляет фронт путём отправки HTTP-запросов...

Для успешного взаимодействия сервисов друг с другом важно, чтобы команды, которые их делают, имели прозрачную коммуникацию. Они пишут документацию (спецификации, спеки, доки, FS, эфэски), которой могут воспользоваться в другой команде для понимания как работать с конкретным сервисом. А ещё (в идеальном мире) они качественно описывают взаимодействие со своим API. Делается это с помощью специальных комментариев в исходном коде сервиса, которые потом хитрым образом обрабатываются сторонним ПО и выдают удобную...

Кратко резюмирую итоги предыдущей части: мы рассматриваем пример обрезанного простого интернет-магазина, построенного на микросервисной архитектуре, где каждый сервис может взаимодействовать с другими сервисами по протоколу HTTP. Давай поподробнее рассмотрим какой-нибудь сервис (не важно какой, пусть будет абстрактный). Как у тебя для взаимодействия с окружающим миром есть глаза, уши, рот и другие части тела (гусары, молчать!), так и у сервиса должны быть какие-то способы общения. Чаще всего для организации такого взаимодействия используется REST-архитектура. Такая архитектура предполагает наличие у сервера определённого API, по которому с ним можно взаимодействовать...

Современная разработка нацелена на ускорение работы разработчиков и оптимизацию бизнес-процессов. Раньше приложения делали монолитными (большой цельный кусок, который разработчики всех мастей делали вместе в одном репозитории), а сейчас один проект дробят на много разных и независимых друг от друга кусочков, которые могут взаимодействовать друг с другом по определённой логике. Ты спросишь, зачем же это нужно, ведь тогда придётся нанимать узкоспециализированных высокоплачиваемых специалистов, чтобы вести разработку. Это аргумент, но с течением времени эти затраты окупаются, потому что не нужно...

Ну что, мой юный падаван автотестировщик, скучал по мне? Сегодня я покажу тебе как использовать DevTools (инструменты разработчика) в любом современном браузере. Для тестировщика это незаменимый инструмент, который позволяет заглянуть под капот веб-приложения, собрать или задать нужные данные. Открыть его можно, нажав на кнопку F12 (или Ctrl+Shift+I, или через Меню - Дополнительные инструменты - Инструменты разработчика, или через контекстное меню - Просмотреть код). В общем, к делу. Без долгих вступлений пойдём по вкладкам, которые явно могут пригодиться...

Как понятно из названия запрос типа GET получает данные от сервера (читает их). Ещё есть POST-запрос (обычно, предназначен для описания создания чего-либо. На самом деле всё зависит от того, как он обрабатывается на сервере: можно завернуть всё так, что POST-запросом можно будет и удалить); PUT-запрос (чаще всего предназначен для обновления уже существующей записи); DELETE-запрос (для удаления) и некоторые другие типы запросов, про которые я тебе не расскажу, сам почитаешь. Кстати говоря, DELETE-запрос тоже тела не имеет, как и GET. Каждый запрос гоняет туда-сюда довольно много интересной информации...

Для отрисовки содержимого страницы браузер делает запрос к серверу для получения контента. Сообщение между браузером и сервером строго регламентировано стандартом. Любой запрос может состоять из двух частей: заголовки и тело. Обе части разделяются двойным переносом строки. Например так: заголовок 1 заголовок 2 тело В некоторых случаях тело может отсутствовать, потому что вся необходимая информация может передаваться в URL. Когда ты вводишь в адресную строку адрес какого-либо сайта, браузер отправляет запрос типа GET к серверу для получения данных. Сервер возвращает ответ том же формате (заголовки и тело), которые обрабатываются браузером...