В предыдущей части я рассказал, что такое WireMock, в каких случаях его необходимо использовать, как его разворачивать и настраивать, как правильно сопоставлять запросы с заглушками и как пользоваться журналированием. Настало время рассмотреть все что связано с HTTP ответом, который возвращает заглушка, а также затронем сценарии.
Содержание
Формирование ответа заглушки
В данном разделе описаны параметры объекта response, который мы немного затронули в первой части. В разделе response есть множество параметров, с ними будем разбираться постепенно, при создании первой заглушки мы столкнулись с такими параметрами как:
status – числовое статическое значение, на вход принимает значение возвращаемого статус кода;
headers – объект в котором находятся заголовки ответа, в качестве ключа объекта выступает название заголовка, в качестве значения ключа выступает значение заголовка;
body – строка, в которая является возвращаемым телом ответа, если туда передавать JSON или XML, то их придется экранировать.
Тело ответа заглушки
Параметры status и headers, являются простыми и с ними ничего особо не сделаешь. Вот параметр тело ответа намного интереснее. Тело ответа можно передать несколькими способами:
body – его уже рассмотрели, простая строка, которая вернется в ответе;
jsonBody – параметр, который принимает на вход JSON, удобен тем, что не нужно экранировать массу символов и передавать в него наглядный JSON с которым удобно работать;
base64Body – строковый параметр, который принимает на вход строку в кодировке base64, удобно если требуется в ответе вернуть файл;
bodyFileName – строковый параметр, который принимает на вход путь до файла, файл должен лежать на сервере в папке __files, данная папка должна находиться в директории, где расположен исполняемый файл WireMock.
Шаблоны
Итак, мы разобрались что тело запроса можно передать несколькими способами, давайте теперь попробуем разобраться с шаблонами. WireMock использует Handlebars шаблоны. Смысл их в том, что мы можем с помощью них делать динамическое тело ответа. Что бы внутрь тела ответа засунуть какую ни будь переменную или функцию их необходимо обрамить в двойные фигурные скобки. В таком случае WireMock вместо шаблона подставит необходимое значение. Отмечу что в таком случае WireMock делает экранирование спецсимволов. В некоторых случаях требуется исключить экранирование значений, которые возвращает переменная и функция, в таком случае необходимо использовать тройные фигурные скобки.
Пример использования шаблонов, после дефиса идет значение, которое подставится:
raw: {{{specialChars}}} - & < > " ' ` =
html-escaped: {{specialChars}} - & < > " ' ` =Переменные
В WireMock есть три источника переменных
Источник переменных – объект request
По объекту request можно получить все параметры HTTP запроса, по которому была сопоставлена заглушка. Ниже описана модель объекта request:
request.url – url в котором есть параметры пути и параметры запроса;
request.path – url в котором есть только параметры пути;
request.pathSegments.[{{n}}] – массив, в котором хранятся все параметры пути по отдельности;
request.query.{{key}} – объект параметров запроса;
request.query.{{key}}.[{{n}}] – массив параметров запроса, которые имеют несколько значений;
request.method – метод запроса;
request.host – hostname на который был отправлен запрос;
request.port – порт сервера на который был отправлен запрос;
request.scheme – протокол запроса;
request.baseUrl – базовый URL без параметров пути и параметров запроса;
request.headers.{{key}} – объект заголовков запроса;
request.headers.[{{key}}] – объект заголовков запроса, используется если в названии заголовка есть спецсимволы;
request.headers.{{key}}.[{{n}}] – массив значений заголовков, которые имеют несколько значений;
request.cookies.{{key}} – объект cookies;
request.cookies.{{key}}.[{{n}}] – массив значений cookies, которые имеют несколько значений;
request.body – тело запроса.
Каждую из этих переменных можно вставить в тело ответа заглушки или как аргумент к функции.
Пример:
{
"request": {
...
},
"response": {
...
"jsonBody": {
"urlPathAndQueryParams": "{{{request.url}}}",
"urlPath": "{{request.path}}",
"urlPathSegment0": "{{request.pathSegments.[0]}}",
"urlPathSegment1": "{{request.pathSegments.[1]}}",
"urlQueryParamId": "{{request.query.id}}",
"urlQueryParamName": "{{request.query.name}}",
"method": "{{request.method}}",
"host": "{{request.host}}",
"port": "{{request.port}}",
"protocol": "{{request.scheme}}",
"baseUrl": "{{request.baseUrl}}",
"headersUserAgent": "{{request.headers.[User-Agent]}}"
},
...
}
}В ответ данная заглушка будет возвращать подробную информацию в формате JSON о параметрах HTTP запроса.
Источник переменных – объект transformerParameters
При формировании заглушки в нее можно передать локальные переменные, которые потом можно использовать в шаблонах, для этого нужно передать параметр transformerParameters, который является объектом, в качестве ключа данного объекта выступает название переменной, в качестве значения ключа выступает значение переменной.
Пример использования transformerParameters:
{
"request": {
...
},
"response": {
...
"jsonBody": {
"value1": "{{parameters.key1}} - {{parameters.key2}}",
"value2": "{{parameters.key1}}",
"value3": "{{parameters.key3}} - {{parameters.key4}} - {{parameters.key5}}"
},
"transformerParameters": {
"key1": "Value1",
"key2": "Value2",
"key3": "Value3",
"key4": "Value4",
"key5": "Value5"
},
...
}
}В данном случае заглушка вернет следующее тело ответа:
{
"value1": "Value1 - Value2",
"value2": "Value1",
"value3": "Value3 - Value4 - Value5"
}Источник переменных – функция systemValue
В WireMock есть не только переменные, но и функции, которые мы рассмотрим в следующих разделах, но тут придется затронуть одну функцию, которая имеет название systemValue, она на вход принимает два аргумента type и key. Эта функция возвращает переменные окружения и свойства, которые были переданы на этапе развертывания WireMock сервера. Аргумент type принимает на вход всего два значения ENVIRONMENT и PROPERTY, для получения переменной окружения или свойства соответственно. Аргумент key принимает на вход название самой переменной.
Пример использования:
{{systemValue type='ENVIRONMENT' key='PATH'}}
{{systemValue type='PROPERTY' key='os.path'}}Функции
Одну из функций рассмотрели выше, в данном разделе подробно рассмотрим основные функции, ведь они дают огромное разнообразие для формирования тела ответа. Некоторые функции не требуют на вход аргументов, но большинство функций в них нуждается. Сами аргументы передаются в формате argument1='valueArgument1', между аргументами должен быть пробел. В качестве значения аргумента могут передаваться не только переменные, но и функции. Если в качестве значения аргумента передается функция, то она будет уже обрамлена не в двойные фигурные скобки, а в круглые скобочки.
Функция now
now – функция, которая возвращает текущие дату и время, без аргументов возвращает дату в формате ISO-8601 по Гринвичу. Имеет два опциональных аргумента offset и format. Первый позволяет сместить текущую дату вперед или назад на определенное значение, второй позволяет задать возвращаемый формат времени, отличный от стандарта ISO-8601.
Пример:
{
"request": {
...
},
"response": {
...
"jsonBody": {
"now date": "{{now}}",
"now date + 3 days": "{{now offset='3 days'}}",
"now date - 24 seconds": "{{now offset='-24 seconds'}}",
"now date + 1 years": "{{now offset='1 years'}}",
"now date + 10 years format yyyy-MM-dd": "{{now offset='10 years' format='yyyy-MM-dd'}}"
},
...
}
}Функция randomValue
randomValue – функция, которая возвращает рандомно значения. Имеет три аргумента type, length и uppercase. Первый обязательный, определяет тип возвращаемых значений, доступны следующие типы:
ALPHANUMERIC – возвращает буквы и цифры;
ALPHABETIC – возвращает буквы;
NUMERIC – возвращает цифры;
ALPHANUMERIC_AND_SYMBOLS – возвращает буквы, цифры и символы;
HEXADECIMAL – возвращает шестнадцатеричный код;
UUID – возвращает идентификатор в формате UUID.
Второй параметр length опциональный, указывает на размерность возвращаемой строки. Третий параметр uppercase, указывает что бы буквы возвращались в верхнем регистре.
Будьте осторожны если вы используете тип ALPHANUMERIC_AND_SYMBOLS внутри JSON, данный тип может вернуть спецсимвол, который не будет экранирован, даже если вы указали двойные фигурные скобки, что естественно поломает структуру JSON и приведет к ошибке на стороне WireMock.
Пример:
{
"request": {
...
},
"response": {
...
"jsonBody": {
"randomValue1": "{{randomValue length=33 type='ALPHANUMERIC'}}",
"randomValue2": "{{randomValue length=12 type='ALPHANUMERIC' uppercase=true}}",
"randomValue3": "{{randomValue length=55 type='ALPHABETIC'}}",
"randomValue4": "{{randomValue length=27 type='ALPHABETIC' uppercase=true}}",
"randomValue5": "{{randomValue length=10 type='NUMERIC'}}",
"randomValue6": "{{randomValue length=25 type='ALPHANUMERIC_AND_SYMBOLS'}}",
"randomValue7": "{{randomValue type='UUID'}}",
"randomValue8": "{{randomValue length=32 type='HEXADECIMAL' uppercase=true}}"
},
...
}
}Функции randomInt и randomDecimal
randomInt – функция, которая возвращает рандомно целое число, если не передавать на вход параметры, то диапазон возвращаемых значений будет от -2147483648 до 2147483647. Имеет два опциональных параметра lower и upper, которые ограничиваю диапазон возвращаемых значений. Первый ограничивает диапазон с меньшей стороны, второй с большей стороны. Оба параметра являются целыми числами. У функции randomInt есть брат randomDecimal, он имеет похожую функциональность только возвращает вещественные чиста. Диапазон возвращаемых чисел 3,4E +/- 38 (7 знаков). Соответственно аргументы являются вещественными числами, которые ограничивают диапазон возвращаемых значений.
Пример:
{
"request": {
...
},
"response": {
...
"jsonBody": {
"randomInt1": "{{randomInt}}",
"randomInt2": "{{randomInt lower=5 upper=9}}",
"randomInt3": "{{randomInt upper=54323}}",
"randomInt4": "{{randomInt lower=-24}}",
"randomDecimal1": "{{randomDecimal}}",
"randomDecimal2": "{{randomDecimal lower=-10.1 upper=-0.9}}",
"randomDecimal3": "{{randomDecimal upper=12.5}}",
"randomDecimal4": "{{randomDecimal lower=-24.01}}"
},
...
}
}Функция jsonPath
jsonPath – функция, которая позволяет вернуть значение определенного ключа (ключей) из структуры JSON используя путь JSONPath. В первой части мы уже сталкивались с JSONPath тут напомню, что это аналог XPath для JSON. Подробнее ознакомиться с JSONPath можно в данном руководстве. Функция принимает на вход два обязательных аргумента сам JSON в котором будет происходить поиск и путь JSONPath.
Пример:
{
"request": {
...
},
"response": {
...
"jsonBody": {
"taskId": "{{jsonPath request.body '$.taskId'}}"
},
...
}
}В данном примере на вход функции jsonPath передается тело запроса, которое будет направлено в сторону заглушки. Если мы отправим запрос к заглушке со следующим телом запроса:
{
"taskId": "444-555",
"result": [
{
"status": "ACTIVE"
},
{
"status": "LOCK"
},
{
"status": "PASSIVE"
}
]
}то в ответе получим следующее тело ответа:
{
"taskId": "444-555"
}Функция join
join – функция, которая делает из массива строку, причем каждый элемент массива разделяется определенными символами. На вход принимает 2 обязательных параметра первый массив, который нужно преобразовать в строку, второй разделитель.
Пример:
{
"name": "Response helpers jsonPath",
"request": {
...
},
"response": {
...
"jsonBody": {
"allStatus": "{{join (jsonPath request.body '$.result[*].status') ', '}}"
},
...
}
}В данном примере на вход функции join передается функция jsonPath, которая возвращает массив найденных элементов. Функция join преобразует этот массив в строку. Если мы отправим запрос к заглушке со следующим телом запроса:
{
"taskId": "444-555",
"result": [
{
"status": "ACTIVE"
},
{
"status": "LOCK"
},
{
"status": "PASSIVE"
}
]
}то в ответе получим следующее тело ответа:
{
"allStatus": "ACTIVE, LOCK, PASSIVE"
}Функция pickRandom
pickRandom – функция, которая на вход принимает множество аргументов, причем рандомно возвращает значение одного из аргументов. Также в данную функцию можно передать один массив, функция вернет рандомно один из элементов данного массива.
Пример:
{
"request": {
...
},
"response": {
...
"jsonBody": {
"randomList": "{{pickRandom '1' '2' '3'}}",
"randomStatus": "{{pickRandom (jsonPath request.body '$.result[*].status')}}",
"randomHelper": "{{pickRandom (now) (randomValue type='UUID') (randomInt)}}"
},
...
}
}В данном примере показаны 3 реализации функции pickRandom. В первом варианте она вернет значения 1 или 2 или 3. Во втором варианте в качестве аргумента будет передан массив данных с найденными статусами, функция вернет значение одного из статусов. В третьем варианте на вход функции передаем три других функции, pickRandom вернет рандомно значение одной из переданных функций.
Пример работы pickRandom с transformerParameters:
{
"request": {
...
},
"response": {
...
"body": "{{{pickRandom parameters.myTestData}}}",
"transformerParameters": {
"myTestData": [
"{\"id\": 1, \"name\": \"Анатолий\", \"age\": 30}",
"{\"id\": 2, \"name\": \"Вика\", \"age\": 21}",
"{\"id\": 3, \"name\": \"Вася\", \"age\": 24}",
"{\"id\": 4, \"name\": \"Петр\", \"age\": 26}",
"{\"id\": 5, \"name\": \"Алёна\", \"age\": 1}",
"{\"id\": 6, \"name\": \"Настя\", \"age\": 2}",
"{\"id\": 7, \"name\": \"Федор\", \"age\": 45}"
]
},
...
}
}В данном примере используется локальная переменная myTestData, которая является массивом, в качестве значений выступают различные данные в виде JSON. Функция pickRandom будет возвращать рандомно один из элементов массива myTestData.
Функция lookup
lookup – функция, которая на вход принимает два параметра, объект и ключ. Результатом функции будет значение по ключу от переданного объекта. Используют в том случае если в ключе содержится спецсимвол, который может поломать синтаксис шаблонов. Также используют в том случае если значением ключа является другая переменная.
Пример:
{
"request": {
...
},
"response": {
...
"body": "{{{lookup parameters request.query.id}}}",
"transformerParameters": {
"key1": "{\"id\": 1, \"name\": \"Анатолий\", \"age\": 30}",
"key2": "{\"id\": 2, \"name\": \"Вика\", \"age\": 21}",
"key3": "{\"id\": 3, \"name\": \"Вася\", \"age\": 24}",
"key4": "{\"id\": 4, \"name\": \"Петр\", \"age\": 26}",
"key5": "{\"id\": 5, \"name\": \"Алёна\", \"age\": 1}",
"key6": "{\"id\": 6, \"name\": \"Настя\", \"age\": 2}",
"key7": "{\"id\": 7, \"name\": \"Федор\", \"age\": 45}"
},
...
}
}Данный пример возвращает определенное значение, на определенный параметр переданный в запросе. В данном случае в функцию lookup передается параметр запроса с ключом id. В объекте transformerParameters находится набор ключей по, которым вернется определенный результат, набор может быть очень большим. Если мы в запросе передадим параметр ?id=key1, то в ответе вернется информация по пользователю Анатолий.
Проксирование
В стандартной ситуации работа с заглушками выглядит следующим образом:
В данном случае весь трафик от веб-сервиса идет на заглушку, при таком подходе можно помешать работе остальным членам команды, которые также тестируют данный инфопоток, либо используют его в каких-то других целях. В таком случает можно прибегнуть к проксированию запросов на целевой веб-сервис. Схема будет выглядеть следующим образом:
В данном случае WireMock запросы, на которые не будет сопоставлена заглушка, будет перенаправлять на целевой реальный веб-сервис. Это позволит не нарушать работу остальных членов команды.
Для того что бы данная схема заработала нужно использовать приоритеты заглушек. За приоритеты в WireMock отвечает параметр priority, это числовой параметр, значение которого лежит в пределе от одного до десяти. Первый приоритет является самым приоритетным, увеличиваясь он теряет свою приоритетность.
Для начала нам нужно сделать проксирование всех запросов на целевой реальный веб-сервис, и данной заглушке выставить самый низкий приоритет, за проксирование отвечает параметр proxyBaseUrl, его значением является строка с адресом на который нужно будет перенаправить запрос:
{
"priority": 10,
"name": "Response proxy",
"request": {
"method": "GET",
"urlPathPattern": "/data.*"
},
"response": {
"proxyBaseUrl": "http://127.0.0.1:3000"
}
}В данном примере мы сделали проксирование запросов на определенный адрес, это может быть любой адрес, который вам требуется.
Если мы хотим заглушить определенные данные, то необходимо сконфигурировать заглушку под эти данные, главное, чтобы приоритет у данной заглушки был выше, чем приоритет проксирующей заглушки:
{
"priority": 1,
"name": "Response mock",
"request": {
"method": "GET",
"urlPathPattern": "/data.*",
"queryParameters": {
"id": {
"equalTo": "111"
}
}
},
"response": {
"status": 200,
"body": "Привет, я заглушка!",
"headers": {
"Content-Type": "text/plain"
}
}
}В данном случае, если будет запрос с параметром id равным 111, то этот запрос не будет проксирован на реальный веб-сервис, а будет заглушен. Все запросы, у которых параметр id будет отличный от 111 будут проксированы на реальный веб-сервис.
Эмуляция не стандартного поведения веб-сервиса
Фиксированная задержка ответа
За фиксированную задержку отвечает параметр fixedDelayMilliseconds, его значением является число, время задержки в миллисекундах.
Пример:
{
"request": {
...
},
"response": {
...
"body": "Я твоя заглушка c задержкой",
"fixedDelayMilliseconds": 2000
}
}В данном случае WireMokc будет на каждый запрос к заглушке, ответ выдавать в течении двух секунд.
Задержка по распределению
За данную задержку отвечает объект delayDistribution, он может реализовать два распределения:
Uniform – непрерывное равномерное распределение, данному распределению необходимо указать нижнюю и верхнюю границы, по которым будут распределятся значения.
Пример uniform распределения:
{
"request": {
...
},
"response": {
...
"body": "Я твоя заглушка c рандомной задержкой",
"delayDistribution": {
"type": "uniform",
"lower": 1000,
"upper": 5000
}
}
}В данном случае время ответа заглушки будет в пределах от одной до пяти секунд, задержка будет распределяться равномерно между этими значениями.
Lognormal – логнормальное распределение. Данное распределение прекрасно эмулирует поведение большей части веб-сервисов. На вход принимает два параметра, медиана и сигма. Медиана является пятидесятым перцентилем задержки, т.е. около 50% запросов будут выполняться до этого времени, остальные 50% будут тянуться длинным хвостом в большую сторону времени ответа. За длину данного хвоста отвечает параметр сигма, чем он больше, тем длиннее хвост. Само распределение можно построить на wolframalpha.
Пример lognormal распределения:
{
"request": {
...
},
"response": {
...
"body": "Я твоя заглушка c логнормальным распределением",
"delayDistribution": {
"type": "lognormal",
"median": 2000,
"sigma": 0.4
}
}
}В данном примере, около 50% запросов к заглушке будет выполняться до двух секунд, остальные запросы будут выполняться от двух до десяти секунд, больший процент запросов будет концентрироваться на начале данного диапазона, в конце диапазона окажутся единицы.
Эмуляция задержки сетевого соединения
За данную задержку отвечает объект chunkedDribbleDelay, он имеет два ключа. numberOfChunks – числовой параметр, который задает на сколько частей будет разбит ответ. totalDuration – числовой параметр, который отвечает за полное время ответа.
Пример:
{
"request": {
...
},
"response": {
...
"body": "Я твоя заглушка c задержкой",
"chunkedDribbleDelay": {
"numberOfChunks": 10,
"totalDuration": 5000
}
}
}В данном примере мы разбили отдаваемый ответ заглушкой на десять частей, причем общее время ответа 5000 миллисекунд. Перед каждой отдаваемой частью ответа WireMock будет делать задержку, в данном примере эта задержка будет составлять 500 миллисекунд. Данными действиями мы можем эмулировать задержки по сетевому соединению.
Эмуляция не стандартных ответов
WireMock может эмулировать ряд нестандартных ответов, полезно при тестировании отказоустойчивости и проверки негативных сценариев. За эмуляцию не стандартных ситуаций отвечает параметр fault, это строковый параметр, который может принимать одно из четырех значений:
EMPTY_RESPONSE – возвращает полностью пустой ответ;
MALFORMED_RESPONSE_CHUNK – отправляет заголовок успешности ответа, затем отправляет мусор и закрывает соединение;
RANDOM_DATA_THEN_CLOSE – отправляет мусор и закрывает соединение;
CONNECTION_RESET_BY_PEER – некорректно закрывает TCP соединение.
Пример:
{
"request": {
...
},
"response": {
"fault": "EMPTY_RESPONSE"
}
}Расширение Webhooks and Callbacks
У WireMock есть расширение Webhooks and Callbacks, которое позволяет делать заглушки в асинхронных инфопотоках, как поднять WireMock с данным расширением, было описано в первой части.
Рассмотрим пример работы асинхронного инфопотока:
В данной схеме инфопоток работает следующим образом, пользователь на Frontend делает заказ, Frontend сформировал запрос в сторону Backend, в свою очередь Backend направляет запрос в сторону другого веб-сервиса на создание задания, данный веб-сервис сразу отвечает 204 кодом, и принимается выполнять задачу. После того как задача выполнена, веб-сервис направляет http запрос c результатом в сторону Backend (это и есть callback). Backend отвечает веб-сервису 204 кодом и направляет ответ с результатом в сторону Frontend. После чего пользователь получает результат выполнения задания на стороне Frontend.
Пример эмуляции данного асинхронного инфопотока на стороне WireMock:
{
"request": {
...
},
"response": {
"status": 204
},
"postServeActions": [
{
"name": "webhook",
"parameters": {
"method": "POST",
"url": "{{{jsonPath originalRequest.body '$.callbackUrl'}}}",
"body": "{\"taskId\":\"{{jsonPath originalRequest.body '$.taskId'}}\",\"result\":\"SUCCESS\"}",
"delay": {
"type": "uniform",
"lower": 5000,
"upper": 10000
}
}
}
]
}В данном примере используется параметр postServeActions, в котором происходит настройка callback. Значением параметра является массив объектов, это означает что мы можем направить не один callback, а несколько, в примере отправляем один callback. Внутри объекта есть параметр parameters, он является также объектом, который содержит в себе три основных составляющих HTTP запроса, это метод, url и тело запроса. Callback обычно отправляется методом POST, в url вставляем ссылку куда нужно отправить сallback, в примере ссылку достаем из тела запроса к заглушке. Ну и также в тело запроса сallback вставляем идентификатор задачи, который пришел в теле запроса к заглушке. А чтобы callback не отправлялся сразу сделали задержку отправления от пяти до десяти секунд.
Если отправим следующий запрос в сторону заглушки:
{
"callbackUrl": "http://127.0.0.1:3000/data",
"taskId": "7cfe8852-829f-4fa0-8d1e-730d9c1531c1"
}то WireMock ответит 204 кодом, и через 5-10 секунд отправит следующий callback запрос:
POST http://127.0.0.1:3000/data
{
"result": "SUCCESS",
"taskId": "7cfe8852-829f-4fa0-8d1e-730d9c1531c1"
}Сценарии
В WireMock есть функциональность сценариев, которые позволяют менять поведение заглушек в зависимости от этапов сценария.
Представим ситуацию что у нас есть веб-сервис, который возвращает чеки, по совершенным ранее покупкам. У данного сервиса есть проверка на аутентификацию пользователя. Если пользователь не авторизован и попробует запросить чеки, то сервис ответит, что пользователь не авторизован, и пользователю потребуется пройти авторизацию, после чего снова запросить чеки, но на этот раз сервис вернет все запрашиваемые чеки, так как пользователь авторизован.
Для работы со сценариями WireMock предоставляет три параметра:
scenarioName – название сценария, по данному параметру WireMock сопоставляет все заглушки сценария. Естественно, у всех заглушек одного сценария должно быть одно и тоже название;
requiredScenarioState – параметр, который указывает заглушке на каком этапе сценария нужно сработать. По умолчанию сценарий всегда начинается с состояния Started;
newScenarioState – параметр, который позволяет определенной заглушке изменить состояние сценария, если произойдет вызов данной заглушки.
Давайте сделаем следующий сценарий:
Получаем чеки – возвращается ответ не авторизован;
Проходим авторизацию – авторизация проходит успешно;
Получаем чеки – возвращается ответ с чеками;
Производим операцию logout – logout проходит успешно;
Получаем чеки – возвращается ответ не авторизован.
Для данного сценария необходимо сделать четыре заглушки:
Первая заглушка, получение чеков, когда пользователь не авторизован:
{
"scenarioName": "MyTestScenario",
"requiredScenarioState": "Started",
"request": {
"method": "GET",
"url": "/check"
},
"response": {
"status": 403,
"jsonBody": {
"status": "error",
"message": "unauthorized"
},
"headers": {
"Content-Type": "application/json"
}
}
}Вторая заглушка, пользователь авторизуется. Данная заглушка меняет состояние сценария на авторизован:
{
"scenarioName": "MyTestScenario",
"newScenarioState": "Authorized",
"request": {
"method": "POST",
"url": "/auth"
},
"response": {
"status": 200,
"jsonBody": {
"access_token": "fdgertg34gdfgdfgdrger",
"refresh_token": "tjgyjtyjtydrjht54yhtj"
},
"headers": {
"Content-Type": "application/json"
}
}
}Третья заглушка, получение чеков, когда пользователь авторизован, данная заглушка схожа по сопоставлению с первой, но реагирует на другой этап сценария:
{
"scenarioName": "MyTestScenario",
"requiredScenarioState": "Authorized",
"request": {
"method": "GET",
"url": "/check"
},
"response": {
"status": 200,
"jsonBody": {
"status": "success",
"message": "success",
"result": [
{
"id": 1,
"check": "88,5"
},
{
"id": 1,
"check": "18,5"
},
{
"id": 1,
"check": "22,3"
}
]
},
"headers": {
"Content-Type": "application/json"
}
}
}Четвертая заглушка, операция logout, происходит смена состояния сценария на не авторизован:
{
"scenarioName": "MyTestScenario",
"newScenarioState": "Started",
"request": {
"method": "POST",
"url": "/unauth"
},
"response": {
"status": 200,
"jsonBody": {
"status": "success",
"message": "Вы успешно разлогинились"
},
"headers": {
"Content-Type": "application/json"
}
}
}Теперь пройдемся по сценарию, описанному выше:
Делаем запрос GET /check, ответ приходит от первой заглушки, не авторизован, так как сценарий в WireMock находится на этапе Started;
Делаем запрос POST /auth, ответ приходит от второй заглушки, также происходит смена этапа сценария со Started в Authorized;
Делаем запрос GET /check, ответ приходит от третьей заглушки, в ответе пришли чеки, так как сценарий в WireMock находится на этапе Authorized;
Делаем запрос POST /unauth, ответ приходит от четвертой заглушки, также происходит смена этапа сценария с Authorized в Started;
Делаем запрос GET /check, ответ приходит от первой заглушки, не авторизован, так как сценарий в WireMock находится на этапе Started.
Принцип сценариев прост, главное понять суть трех новых параметров, которые мы рассмотрели в данном разделе. Если комбинировать сценарии с приоритетами заглушек, то можно делать более сложные кейсы.
Подведем итоги
WireMock это мощный инструмент, с помощью которого можно воспроизвести практически любое поведение HTTP веб-сервиса, причем для настройки заглушек не требуется знаний языков программирования, а само API настройки заглушек обладает широкой функциональностью, которую легко и быстро реализовать на практике.
WireMock также прекрасно подходит для работы со сценариями в нагрузочном тестировании, на своем опыте убедился что он выступает скалой, которая устоит под любым шквалом запросов, главное правильно его настроить.
С использованием заглушек у тестировщиков, системных аналитиков и разработчиков сильно развязываются руки, позволяя делать больше не стандартных кейсов
Отмечу что WireMock можно использовать не только в ручном и нагрузочном тестировании, но и в автоматизации. Есть множество кейсов использования WireMock в автоматизации, но это тема совершенно другой статьи.
