Хабрахабр

TestMace. Быстрый старт

Мы потихоньку выходим из тени и продолжаем серию статей о нашем продукте. Всем привет. Сегодня мы покажем TestMace в деле и вы по достоинству сможете оценить некоторые фишки нашего приложения. После предыдущей обзорной статьи мы получили множество отзывов (преимущественно положительных), предложений и bug репортов. Итак, поехали! Для более полного погружения советую обратиться к нашей документации по адресу http://docs-ru.testmace.com.

Приложение доступно и реально тестируется на трех платформах — Linux, Windows, MacOS. Начнем с банальщины. Для линуксоидов есть возможность установки snap пакета. Вы можете скачать установщик для интересующей ОС с нашего сайта. Как думаете?). Очень надеемся, что скоро дойдут руки и до Microsoft Store и App Store (А надо ли?

В качестве испытуемого мы выбрали следующий стандартный сценарий:

  • залогинимся: пользователь — admin, пароль — password
  • добавим новую запись
  • проверим корректное добавление записи

Это обычный json-server, прекрасно подходящий для тестирования подобных приложений. Тестировать будем на https://testmace-quick-start.herokuapp.com/. Двигаться будем поступательно, постепенно усовершенствуя наш проект. Мы только добавили авторизацию по токену на все роуты json-server-а и сделали метод login для получения этого самого токена.

Создание проекта и попытка создать сущность без авторизации

Если вы запускаете приложение впервые, то новый проект откроется автоматически. Для начала создадим новый проект (File->New project). Выберите в контекстном меню Project узла пункты Add node -> RequestStep. Для начала попробуем сделать запрос на создание новой записи (вдруг создание записей доступно без авторизации). В результате в дереве создастся новый узел и откроется вкладка данного узла. В качестве имени узла зададим create-post. Зададим следующие параметры запроса:

  • Тип запроса: POST
  • url: https://testmace-quick-start.herokuapp.com/posts
  • Тело запроса: json со значением
    Если вы все сделали правильно, то интерфейс будет выглядеть следующим образом:

Ну, в общем-то, ожидаемо). Однако если мы попробуем выполнить запрос, то сервер возвратит 401 код и без авторизации нам на этом сервере ничего не светит.

Добавляем запрос на авторизацию

В ответ данный endpoint возвращает json вида {"token": "<token>"}. Как уже было сказано, у нас есть POST endpoint /login, который принимает в качестве тела запроса json вида: {"username": "<username>", "password": "<password>"}, где username и password (опять таки, из вводной выше) имеют значения admin и password соответственно. Создадим RequestStep узел с именем login, в качестве предка будет выступать Project узел. Воспользуемся им для авторизации. Зададим вновь созданному запросу следующие параметры: С помощью drag-and-drop переместите данный узел в дереве выше, чем узел create-post.

Как-то так: Выполним запрос и получим двухсотый код с токеном в ответе.

Рефакторинг: убираем дублирование домена

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

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

Для этого необходимо Определим на уровне Project узла переменную domain со значением https://testmace-quick-start.herokuapp.com.

  • Открыть вкладку с данным узлом и нажать на иконку калькулятора справа вверху
  • Нажать на + ADD VARIABLE
  • Ввести имя и значение переменной
    В нашем случае диалог с добавленной переменной будет выглядеть следующим образом:

Теперь за счет наследования мы можем использовать данную переменную в потомках любого уровня вложенности. OK. Для того, чтобы в текстовом поле использовать переменную, необходимо написать ${<variable_name>}. В нашем случае это узлы login и create-post. Например, url для логина преобразуется в ${domain}/login, соответственно для create-post узла url будет выглядеть как ${domain}/posts.

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

Сохраняем токен в переменную

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

Во вкладке Parsed ответа наведите курсор на токен и в контекстном меню (которое вызывается либо правой кнопкой мыши, либо нажатием на кнопку ...) выберите пункт Assign to variable. Для начала выполним запрос на логин. Появится диалог со следующими полями:

  • Path — какой кусок ответа берется (в нашем случае это body.token)
  • Current value — какое значение лежит по пути Path (в нашем случае это значение токена)
  • Variable name — название переменной, куда Current value будет сохраняться. В нашем случае это будет token
  • Node — в каком из предков будет создана переменная Variable name. Выберем Project

Заполненный диалог выглядит следующим образом:

И эта переменная будет храниться в Project узле и благодаря наследованию будет доступна потомкам. Теперь при каждом выполнении узла login динамическая переменная token будет обновляться новым значение из ответа.

Например, чтобы достучаться до сохраненного токена, необходимо вызвать ${$dynamicVar.token}. Для того, чтобы обратиться к динамическим переменным, необходимо использовать встроенную переменную $dynamicVar.

Прокидываем авторизационный токен в запросы

Для этого есть несколько способов: На предыдущих шагах мы получили авторизационный токен и все, что нужно сделать, это добавить заголовок Authorization со значение Bearer <tokenValue> во все запросы, требующие авторизации, в том числе и в create-post.

  1. Вручную скопировать токен и добавить авторизационный заголовок в интересующие запросы. Способ рабочий, однако его применение ограничивается только запросами вида "сделал и выкинул". Для многократного выполнения сценариев не подойдет
  2. Воспользоваться функционалом авторизации.
  3. Использовать заголовки по умолчанию

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

Если в двух словах, то заголовки по умолчанию — это наследуемые от предков HTTP-заголовки, которые по умолчанию добавляются к запросу, если их явно не отключить. Другое дело заголовки по умолчанию! Применим данную фичу для прокидывания токена в заголовках. С помощью данного функционала можно к примеру, реализовать кастомную авторизацию или просто избавиться от дублирования в сценариях.

Остается сделать следующее: Ранее мы предусмотрительно сохранили токен в динамическую переменную $dynamicVar.token на уровне Project узла.

  1. Определить заголовок по умолчанию Authorization со значением Bearer ${$dynamicVar.token} на уровне Project узла. Для этого в интерфейсе Project узла необходимо открыть диалог с заголовками по умолчанию (кнопка Headers в правом верхнем углу) и добавить соответствующий заголовок. Диалог с заполненными значениями будет выглядеть следующим образом:
  2. Выключить данный заголовок из login запроса. Это и понятно: на момент логина у нас еще нет токена и мы этим запросом как раз таки установим его. Поэтому в интерфейсе login запроса во вкладке Headers в области Inherited уберем галочку с Authorization заголовка.

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

Проверяем корректность создания поста

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

  • Отправить запрос на получение поста по id,
  • Проверить, что имя, пришедшее с сервера, соответствует имени, переданному при создании поста

Раз значение id определяется во время выполнения скрипта, необходимо создать динамическую переменную (назовем ее postId) из узла create-post на уровне Project узла. Рассмотрим первый шаг. Остается только создать запрос на получение поста по данному id. Как это сделать мы уже знаем, достаточно обратиться к разделу Сохраняем токен в переменную. Для этого создадим RequestStep get-post со следующими параметрами:

  • Тип запроса: GET
  • URL: ${domain}/posts/${$dynamicVar.postId}

Assertion узел — это узел, позволяющий писать проверки на определенные запросы. Для реализации второго шага нам необходимо познакомиться с Assertion узлом. Подробнее обо всех видах assertion-ов вы сможете прочитать из нашей документации. Каждый Assertion узел может содержать несколько утверждений (проверок). Есть несколько способов создания assertion-ов: Мы будем использовать Compare assertion с оператором equal.

  1. Долгий. Вручную из контекстного меню RequestStep узла создать Assertion узел. В созданном Assertion узле добавить интересующий assertion и заполнить поля.
  2. Быстрый. Создать Assertion узел вместе с assertion-ом из ответа RequestStep узла с помощью контекстного меню

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

Для тех кто не понял, тут происходит следующее:

  1. Сделать запрос в узле get-post
  2. Во вкладке Parsed ответа вызвать контекстное меню и выбрать Create assertion -> Compare -> Equal

Просто, не правда ли? Поздравляю, мы создали первый тест! Остается совсем чуть-чуть отрефакторить и вынести title в отдельную переменную. Теперь можете запустить сценарий полностью и наслаждаться результатом. Но мы оставим это вам в качестве домашнего задания)

Разумеется, мы воспользовались далеко не всем функционалом и в следующих статьях мы проведем детальный обзор возможностей TestMace. В данном руководстве мы создали полноценный сценарий и заодно провели обзор некоторых фич нашего продукта. Следите за обновлениями!

S. P. Открыть его можно с помощью File -> Open project и выбрать папку Project. Для тех, кому лень воспроизводить все шаги, мы любезно запилили репозиторий с проектом из статьи.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть