mock server что это

Что нужно знать про Postman: максимально коротко о Mock Servers, Flow и Visualize

На просторах интернета часто встречается информация о платформе Postman. Большинство статей включают информацию о переменных, различных скриптах и автоматизации при тестировании. Но на самом деле Postman – это не только инструмент для тестирования, а платформа, которая помогает с помощью обширного набора инструментов ускорить жизненный цикл разработки API — проектирование, тестирование, документирование, имитацию и совместное использование проектов.

В этой статье я решил сделать краткий обзор функциональности Visualize, Mock Servers и Flow.

Создание Mock Service

Начнем с создания Mock-сервера, который позволяет имитировать взаимодействие сервисов. Функционал Postman позволяет легко редактировать и масштабировать мок-сервера, а одной из особенностей настройки сервера является возможность генерировать случайные значения в теле ответа.

Для создания Mock-сервера на левой панели выбираем Mock Servers → Create Mock Servers (возможно создание нажатием на +).

1. Настроим свой сервер в таблице (в дальнейшем все параметры можно изменить):

Request Method

Request URL

Response Code

Response Body

Удобнее задать на следующих этапах

1. Заполним поле Mock server name и укажем окружение переменных (Environment). Доступны опции:

• Сохранить сервер в качестве переменной (будет создано новое окружение переменных);
• Сделать сервер приватным. В данном случае, в запросах необходимо использовать x-api-key сгенерированный в Postman;
• Имитировать фиксированную сетевую задержку.

Результаты создания сервера:

• Система генерирует уникальный url созданного сервера;
• Система создает коллекцию с указанным названием сервера, в нашем случае это будет HabrMock;
• Система формирует запросы вида >+Request URL и размещает их в коллекции HabrMock.

Настроим сервер для POST orders/habr.

1. Исправим название сервиса Default, на код ответа, который будет обрабатывать сервер (201).
2. Зададим параметры ответа сервера:

Существуют 3 способа сформировать данные в ответе сервера:

Способ

Пример

Ответ с динамической переменной

Динамическая переменная предоставляет случайные данные. Чтобы использовать динамические переменные в сценариях предварительного запроса или тестирования (вкладки pre-request-Script и Tests), вам необходимо использовать функцию pm.variables.replaceIn() , например, pm.variables.replaceIn(‘>’) . Со списком динамических переменных можно ознакомится по ссылке.

На примере это будет выглядеть так:

Запрос POST >/orders/habr :

Mock Servers body:

На данном этапе мы сформировали Mock Server для запроса POST, который имитирует создание order, в теле ответа мы возвращаем всю необходимую информацию. Данный сервер можно использовать для тестирования или беспрерывной разработки.

Cценарий Flow

Flow (потоки) – новый функционал Postman. Недавно закончилось его бета-тестирование и добавлена стабильная и рабочая версия. Основной идеей Flow является разработка тестовых сценариев без использования кода во вкладке «tests» и «Pre-reques script».

Например, для объявления переменной, которую мы хотим извлечь из тела ответа, во вкладке «tests» необходимо прописать код:

var jsonData = JSON.parse(responseBody); pm.environment.set("number", jsonData.id);

При использовании Flow можно обойтись без кода:

1. Добавим первый блок «Send request». Выберем запрос и окружение переменных:

1. Добавим блок «Create Durables» и соединяем Response – Data:

1. «Create Durables» предназначен для определения переменных. В конфигурации блока необходимо заполнить таблицу:

Key

Value

(Указываем ключ, данное значение будет использовано в следующем запросе)

(Какое значение будет найдено и использовано, в данном примере number. После первого вызова, выстраивается вложенность данных, которую удобно выбирать из списка)

1. Добавим блок «Send request», в котором будем использовать значение numberOrders:

1. В блоке GET /orders/> задается использование данных в переменной. В конфигурации (либо Add Variables) необходимо заполнить таблицу:

Varable

Current Value

(переменная, в которую подставляем значение)

(значение, которое будет подставлено в переменную number)

Мы реализовали простейший сценарий, при выполнении первого запроса создается заявка, и в ответе мы получаем ее номер (number). Далее мы извлекаем из ответа номер заявки и переиспользуем его в следующем запросе.

Таким образом, блоки Flow предоставляют множество функций, которые сложно реализовать с помощью кода.

Визуализация ответов

Postman предоставляет программируемый способ визуального представления ответов на запросы. Код визуализации, добавленный в «tests» для запроса, будет отображаться на вкладке «Visualize».

Для визуализации ответа, в Postman используется метод pm.visualizer.set() . Метод принимает три параметра:

• layout (обязательно) — это строка HTML-шаблона Handlebars;
• data (необязательно) — это данные, которые вы можете привязать к шаблону. Доступ к свойствам этого объекта можно получить в шаблоне;
• options (необязательно) — это options объект для Handlebars.compile(). Вы можете использовать это, чтобы контролировать, как Handlebars компилирует шаблон.

Визуализируем ответ в виде таблицы. Допустим, у нас есть GET запрос, в ответе мы получаем JSON с множеством параметров:

Во вкладке tests выполним следующее:

1. Сформируем строку HTML-шаблона.

var template = ` .tftable .tftable th .tftable tr .tftable td .tftable tr:hover  Пользователь МРФ Тип работы 

1. Выполним циклический опрос JSON на наличие параметров:

> > onClick="handleClick(this.id)"> >>> > >  > `;

1. Задействуем метод визуализации:

pm.visualizer.set(template, );

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

Визуализация предоставляет возможность работы с данными ответа в удобном виде. Так, например, можно использовать код HTML (скопированный через консоль разработчика) в Confluence. Для этого необходимо на странице Confluence разместить макрос HTML и вставить в рамку скопированный код HTML. Данный макрос выполнит HTML код при открытии страницы. Confluence распознает таблицу и даже позволит воспользоваться сортировкой, фильтрами и экспортом в различные форматы.

Вместо выводов

Я описал лишь малую часть интересной функциональности Postman. Мне бы хотелось, чтобы данная статья показала вам, что Postman может быть не только обычным инструментом для тестирования API, но и многофункциональной платформой, способной решать различные задачи в ходе работы с интеграционным слоем.

• Блог компании Ростелеком
• Тестирование IT-систем
• API
• Тестирование веб-сервисов

Mock-сервисы для тестирования: How to use + Quick start

В подавляющем большинстве этот термин знаком всем и его сущность ни для кого не является секретом. Но, по традиции, все же лучше начать с определения:

11 показов
14K открытий

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

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

На хабре достаточно статей по данной тематике. Наш QA-инженер–Николай – хочет остановиться на кратком руководстве для старта с общим обзором и примерами по одним из самых популярных инструментов. Дабы была возможность быстро определить перечень используемых инструментов и в дальнейшем продолжить уже их более углубленное изучение.

В данной статье будут приведены примеры с локальным развертыванием. Этот вариант идеально подойдет, если тестируемое приложение развернуто на рабочей машине. Если же стоит задача развернуть заглушку для удаленного сервиса, тут лучше обратиться к девопсам/администраторам. Т.к. политика безопасности не всегда дает доступ на сервер с крутящимся на нем приложением, а перед тем как будущая заглушка начнет отрабатывать – сервис придется перенастроить и перезагрузить. Иными словами сломать. Еще ни одного тестировщика за такие фокусы не похвалили. Потому в данной статье этот вопрос подниматься не будет.

Немного теории

Существует несколько видов объектов, которые позволяют симулировать поведение реальных объектов во время тестирования:

• Dummy — пустые объекты, которые передаются в вызываемые методы, но не используются. Предназначены лишь для заполнения параметров методов.
• Fake — объекты, которые имеют реализации, но в таком виде, который делает их неподходящими для использования в рабочей ситуации.
• Stub — предоставляют заранее заготовленные ответы на вызовы во время теста и не отвечают ни на какие другие вызовы, которые не требуются в тесте.
• Mock — объекты, которые заменяют реальный объект в условиях теста и позволяют проверять вызовы своих методов. Содержат заранее подготовленные описания вызовов, которые они ожидают получить. Применяются в основном для тестирования поведения пользователя.

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

Старый и всем давно известный инструмент. Пригоден как для тестирования SOUP, так и REST сервисов, автоматизации их проверок и создания заглушек.

Для тех, кто все еще путается:

REST и SOAP не сопоставимы!

— REST — это архитектурный стиль, оперирующий JSON через HTTP.

— SOAP — это формат обмена XML сообщениями с ограничениями по структуре сообщений через HTTP.

Рассмотрим на примере REST сервиса. Для SOAP шаги будут идентичными и не вызовут особых трудностей.

При первом запуске автоматически всплывает окно Endpoint Explorer, в котором необходимо указать сам запрос и необходимые для работы заголовки:

После пробного запроса получаем ошибку, что такой ресурс не существует. Сюда же можно отнести случай, когда сервис есть, но возвращает не совсем то, что нужно:

Mock-тестирование: что это, для чего нужно и как проводится

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

Mock-тестирование — это почти то же самое, что и автомобильный краш-тест, только вместо антропоморфных болванчиков инженеры используют тестовые двойники — моки. В этой статье мы расскажем, что такое моки, как их создают и почему они иной раз могут навредить. А заодно проведём mock test — потренируемся в написании собственных программных двойников.

Что такое Mock-тестирование

Mock-тестирование — это испытание программы, при котором реальные её компоненты заменяются «дублёрами» — тестовыми объектами. Ими могут быть фейковые базы данных, почтовые серверы и другие сложные системы. Тестовые объекты лишь подражают настоящим, но не содержат реальной логики или данных.

Существует два основных вида тестовых объектов — моки и стабы, у которых тоже есть несколько разновидностей. Такая система может показаться запутанной, но не переживайте — сейчас во всём разберёмся.

Мок — это тестовый объект, который помогает имитировать исходящие зависимости (команды). «Исходящие» означает, что программа обращается к другим системам, чтобы получить или изменить какие-то данные.

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

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

Стаб — это тестовый объект, который имитирует внешние воздействия (запросы). Допустим, мы написали класс, который получает данные о погоде из другого сервиса и возвращает их в приложение. Чтобы во время тестов не отправлять реальные запросы сервису, можно написать стаб — заглушку, которая будет формировать запрос и возвращать фиксированное значение температуры.

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

Перечислим и основные виды стабов:

• Dummy — упрощённая версия стаба, которая используется как заполнитель. Поведение Dummy игнорируется, он нужен, чтобы удовлетворить требованиям компилятора. Простой пример dummy — популярная новичковская программа «Hello, world».
• Fake — объект посложнее. Он не просто заполняет место в коде, но и умеет возвращать разные значения в зависимости от сценария. Пример фейка — тестовая коллекция, которая имитирует работу базы данных.

Независимо от того, какой вид тестового объекта вы используете: mock, spy, stub, fake или dummy, в процессе тестирования их всё равно будут называть моками — так уж сложилось. Но вы теперь знаете, что под этим термином могут скрываться самые разные виды тестовых болванчиков.

Когда стоит использовать Mock

В мире разработки сложилось общее мнение, что заменять на моки стоит только такие системы, которые не являются частью программы, но с которыми она может проводить манипуляции — например, базы данных, почтовые серверы, файловые системы, шины сообщений и так далее. По-научному такие системы зовутся довольно негуманно: «изменяемые внепроцессорные зависимости».

Действительно, нет никакого смысла заменять на моки зависимости, которые и так находятся внутри приложения. Тесты, написанные для испытания таких объектов, получатся хрупкими — то есть нацеленными на детали исполнения, а не на конечный результат. Гораздо лучше написать готовый объект и протестировать неповторимый оригинал вместо жалкого подобия.

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

Более совершенную модель использования моков предлагает Владимир Хориков в своей статье When to Mock (есть перевод на «Хабре»). В ней он приходит к выводу, что мокать стоит только неуправляемые внепроцессорные зависимости — то есть те, над которыми у вас нет непосредственного контроля.

Допустим, мы тестируем работу класса PaymentProcessor, который обрабатывает входящие платежи. Для обработки платежей он использует внешний платёжный шлюз. Шлюз описан в классе PaymentGateway, к которому у нас нет доступа.

Платёжный шлюз PaymentGateway — это неуправляемая зависимость, потому что он взаимодействует с внешними платёжными системами, к которым у нас нет доступа. А так как мы не хотим тратить настоящие деньги, чтобы протестировать платёжный шлюз, имеет смысл создать для его имитации мок-объект.

Тут есть сразу две выгоды:

• Мы изолируем свой класс от внешних систем. Наша цель — проверить, как PaymentProcessor обрабатывает платежи, а не как работают внешние платёжные системы. Мокирование PaymentGateway изолирует тестирование PaymentProcessor от реальных платёжных систем.
• Мы сможем реализовать любые тестовые сценарии. Например, настроить мок PaymentGateway так, чтобы он эмулировал ответы платёжных систем для успешных и неуспешных платежей.

Стоит оговориться, что мокать внутренние компоненты тоже иногда допустимо. Например, вы собираетесь добавить компонент Б, чтобы протестировать компонент А, но это почему-то невозможно сделать сейчас — например, тимлид ещё не успел определиться с библиотекой или нужно долго ковыряться в JSON. В этом случае допустимо мокнуть Б, чтобы работа над А не простаивала. Но лучше таким подходом не злоупотреблять.

Инструменты для mock-тестирования

С теорией разобрались, настало время перейти к практике. Для начала соберём базовый набор инструментов для mock-тестирования на Python.

Unittest

Unittest — это модуль стандартной библиотеки Python. Внутри есть фреймворк для создания и запуска тестов. С его помощью можно создавать мок-объекты, которые имитируют поведение зависимых компонентов и помогают изолировать тестируемый код. Нельзя лишь имитировать внешние сервисы.

Плюсы: простой синтаксис для создания моков.

Минусы: ограниченная имитация внешних серверов, так как Unittest не предоставляет удобных средств для создания мок-серверов и эмуляции внешних HTTP-сервисов.

Pytest.mock

Pytest.mock — это модуль библиотеки Pytest. В ней гораздо больше возможностей для создания мок-объектов, чем в Unittest, но и пользоваться ей сложнее.

Плюсы: позволяет гибко настраивать поведение моков и проверять вызовы методов.

Минусы: синтаксис сложноват для новичков.

Postman

Postman — это готовый инструмент для тестирования API и создания HTTP-запросов. Умеет создавать мок-серверы для эмуляции поведения API — удобно тестировать взаимодействие с внешними сервисами.

Плюсы:

• Интуитивно понятный интерфейс для создания HTTP-запросов и тестирования API.
• Возможность создания мок-серверов для эмуляции поведения API.
• Хорошая интеграция с различными сервисами и инструментами для тестирования.
• Независимость от языка программирования.

Минусы:

• Не подходит, если нужно мокать что-то, кроме API и HTTP-запросов.
• В бесплатной версии доступно только 1000 моков в месяц.

Готовимся к работе

В следующих разделах мы попробуем создать несколько моков для имитации двух видов зависимостей — внешней и внутренней. Но для начала нам необходимо настроить всю необходимую инфраструктуру.

В первую очередь мы предполагаем, что у вас уже установлен Python. Если нет, то установите — скачайте инсталлятор с официального сайта. Установить его не сложнее, чем «Яндекс Браузер», — просто следуйте инструкциям. Чтобы проверить, что всё установилось как надо, откройте командную строку (на Windows это делается с помощью комбинации Win + R) и введите:

В противном случае cmd просто не поймёт, чего вы хотите:

Мы настоятельно рекомендуем воспользоваться интегрированной средой разработки (IDE) — это избавит вас от головной боли прописывания системных путей и импортов. У нас это PyCharm, установить её легко — запустите установочный файл с официального сайта и следуйте инструкциям.

Ещё мы покажем, как создавать моки в Postman. Если вы больше тестировщик, чем разработчик, то вы рано или поздно с ним столкнётесь. Установить Postman тоже проще простого — скачайте установочный файл с официального сайта, а дальше он вас сориентирует.

Mock-тестирование с внутренними зависимостями

Идея такая — нам надо протестировать обработчик заказов.

Создайте проект test_example — при работе в PyCharm так же будет называться его корневая папка. Внутри создайте файл order.py — то, что мы будем тестировать:

Тест пройден, если метод send_notification у мок-объекта mock_notification_service вызывается ровно один раз с указанными аргументами. А мы в этом случае получаем такое сообщение:

Проведём ещё пару тестов с нашим Order. Добавьте следующие тестовые функции в класс TestOrder:

Но что, если наш тестовый класс просто сообщает хорошие новости вне зависимости от фактического успеха? Давайте проверим. Добавьте в TestOrder намеренно провальную тестовую функцию:

Mock-тестирование с внешними зависимостями

Теперь рассмотрим случай, когда ваш компонент должен взаимодействовать с тем, к чему у вас нет доступа. Для этого создадим мок удалённого сервера, который будет передавать нашему приложению данные о погоде.

Создайте новый проект MockServerTest. В корневой папке создайте два файла — weather_app и mock_server. Также создайте папку tests. Но сначала напишем класс WeatherServise в файле weather_app:

На следующем экране оставьте метод без изменений (GET), в поле url укажите weather, код оставьте без изменений (200), в response body вставьте JSON-подобную конструкцию. У нас будет просто . Нажмите Next.

var jsonData = JSON.parse(responseBody); pm.environment.set("number", jsonData.id);

var template = ` .tftable .tftable th .tftable tr .tftable td .tftable tr:hover  Пользователь МРФ Тип работы 

> > onClick="handleClick(this.id)"> >>> > >  > `;

pm.visualizer.set(template, );