Вступление

В предыдущей статье Тестирование gRPC мы с вами рассмотрели тестирование сервиса, между сервером и клиентом которого, происходит общение посредством фреймворка gRPC. Этот фреймворк использует передовые технологии, применение которых, позволило ему вырваться вперед и обойти всем известный REST. Структура использования HTTP/2, буферов протоколов и других современных технологических стеков, обеспечивает максимальную безопасность, производительность и масштабируемость API. И само собой, тестирование этих сервисов немного отличается от привычного нам REST. К сожалению, рассмотрев основные нюансы в предыдущей статье, была упущена одна небольшая деталь, которая значительно упрощает и облегчает жизнь тестера и не только. Вот как раз на неё то и обратил внимание мой коллега, разработчик Александр Смыслов. В нашей команде он играет роль локомотива прогрессивных идей и нововведений. Благодаря ему мы переключались на новые инструменты тестирования и применяли инновационные подходы и технологии. Вот и в этот раз, он помог доработать сервис и улучшить его с помощью gRPC Server Reflection Protocol.

Установка и запуск

Для того чтобы воспользоваться преимуществами gRPC Server Reflection Protocol необходимо сначала локально установить и запустить наш демо проект. Для этого скачиваем проект из репозитория https://github.com/MikhailPO/grpcExampleService с помощью команды git clone

Командой cd grpcExampleService/ переходим в папку grpcExampleService

Для корректной работы сервиса необходимо установить официальный пакет Server Reflection с помощью команды pip install grpcio-reflection

Для того чтобы наш сервис начал функционировать, делаем все наши sh файлы запускаемыми, выполнив команду find . -name "*.sh" -exec chmod +x {} \;

На этом, подготовительный этап закончен и можно переходить непосредственно к установке и запуску сервиса. Для этого необходимо создать все файлы нашего проекта при помощи команды ./generate_file.sh

Устанавливаем наш сервис командой install.sh

И запускаем его командой start.sh

Теперь наш сервис запущен и работает на локальном хосте с портом 50051 localhost:50051

Тестирование

Как уже упоминалось в первой части статьи Тестирование gRPC перед началом тестирования сервиса, необходимо один раз произвести настройку инструмента для тестирования. Работу с фреймворком gRPC поддерживают не все инструменты. Из тех что я знаю, возможность тестирования gRPC реализована в Postman, Insomnia, BloomRPC, Kreya и Fint. В нашем случае будет использоваться Postman.

Проведем небольшую подготовку нашего инструмента, то есть залогинимся в наш аккаунт в Postman. Либо создадим новый аккаунт и войдем в него. Потому что gRPC запросы не работают если не зайти в свой аккаунт.

Теперь все готово чтобы создать gRPC запрос. Нажимаем кнопку New и выбираем gRPC Request

В окне Enter server URL вводим URL и порт нашего сервиса:

Всё, теперь можно тестировать сервис.

Если кликнуть мышкой на окно Select a method , то появится выпадающий список всех API, которые доступны в сервисе и могут быть использованы для тестирования.

Теперь нет необходимости загружать proto файл для их отображения, как мы это делали в первой части статьи. Все методы подгружаются автоматически с помощью Server Reflection Protocol. gRPC Server Reflection Protocol предоставляет информацию об общедоступных сервисах gRPC на сервере и помогает клиентам во время выполнения создавать запросы и ответы RPC без предварительно скомпилированной информации о сервисе. Таким образом мы имеем автоматическую загрузку методов при создании нового запроса. Но и это еще не всё. При добавлении разработчиком новых методов в сервис, тестеру достаточно сделать рефреш, нажав на стрелку рядом с Using server reflection и он моментально получит, только что созданные методы, к себе в коллекцию.

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

Еще один нюанс, на который я обратил внимание, это невозможность сохранить gRPC запрос в коллекцию REST запросов. Скорее всего это связано с тем, что REST использует HTTP/1.x для передачи данных в то время, как gRPC использует HTTP/2.

Заключение

gRPC — многообещающая технология, которая уже получила значительное распространение в области API. gRPC обладает высокой скоростью и эффективностью, что особенно полезно в архитектуре микросервисов. Однако это не замена REST, так как gRPC почти не поддерживается современными браузерами. С другой стороны, в связи с увеличением количества систем на микросервисах, растет потребность в их тестировании и возможно часть из них будет использовать gRPC, а в некоторых компаниях уже используют, таких как Netflix, Cisco и другие. Поэтому современный тестер обязан иметь представление о тестировании сервисов использующих фреймворк gRPC. И надеюсь, мой цикл статей о нем хоть немного способствовал этому.

Завершить статью хочу приглашением на бесплатный урок, где мы разберем в целом контейнеризацию и тонкости работы Docker. Затронем тему namespaces и cgroup и их роль в контейнеризации. Так же на уроке рассмотрим СХД (системы хранения данных в Docker) и конечно же поговорим про сети в контейнерах Docker.

Комментарии (0)