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

Встановлення

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

Піддослідний сценарій

Як випробуваний ми вибрали наступний стандартний сценарій:

• залогінимся: користувач - admin, пароль - password
• додамо новий запис
• перевіримо коректне додавання запису

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

Створення проекту та спроба створити сутність без авторизації

Для початку створимо новий проект (філе->Новий проект). Якщо ви запускаєте програму вперше, новий проект відкриється автоматично. Спочатку спробуємо зробити запит на створення нового запису (раптом створення записів доступне без авторизації). Виберіть у контекстному меню Project вузла пункти Додати вузол -> RequestStep. Як ім'я вузла поставимо create-post. У результаті дереві створиться новий вузол і відкриється вкладка даного вузла. Задамо наступні параметри запиту:

• Тип запиту: POST
• URL: https://testmace-quick-start.herokuapp.com/posts
• Тіло запиту: json зі значенням {"title": "New testmace quick start post"}
  Якщо ви все зробили правильно, то інтерфейс буде виглядати так:

Однак, якщо ми спробуємо виконати запит, то сервер поверне 401 код і без авторизації нам на цьому сервері нічого не світить. Ну, загалом, очікувано).

Додаємо запит на авторизацію

Як уже було сказано, ми маємо POST endpoint /login, який приймає як тіло запиту json виду: {"username": "<username>", "password": "<password>"}, Де username и password (Знову-таки, з вступної вище) мають значення admin и password відповідно. У відповідь даний endpoint повертає json вигляду {"token": "<token>"}. Скористаємося ним для авторизації. Створимо RequestStep вузол з ім'ям Логін, як предок виступатиме Проекти вузол. За допомогою drag-and-drop перемістіть цей вузол у дереві вище, ніж вузол. create-post. Задамо новоствореному запиту наступні параметри:

• Тип запиту: POST
• URL: https://testmace-quick-start.herokuapp.com/login
• Тіло запиту: json зі значенням {"username": "admin", "password": "password"}

Виконаємо запит і отримаємо двохсотий код із токеном у відповіді. Якось так:

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

Поки що запити не пов'язані в єдиний сценарій. Але це не єдиний недолік. Якщо придивитися, можна помітити, що як мінімум домен дублюється в обох запитах. Не добре. Саме час відрефакторити цю частину майбутнього сценарію, і в цьому нам допоможуть змінні.

У першому наближенні змінні виконують ту саму роль, що і в інших подібних інструментах та мовах програмування - усунення дублювання, підвищення читабельності тощо. Докладніше про змінні можна почитати в нашої документації. В даному випадку нам знадобляться змінні користувача.

Визначимо на рівні Project вузла змінну domain зі значенням https://testmace-quick-start.herokuapp.com. Для цього необхідно

• Відкрити вкладку з цим вузлом та натиснути на іконку калькулятора праворуч угорі
• Натиснути на + ADD VARIABLE
• Ввести ім'я та значення змінної
  У нашому випадку діалог з доданою змінною буде виглядати так:

Добре. Тепер за рахунок успадкування ми можемо використовувати цю змінну у нащадках будь-якого рівня вкладеності. У нашому випадку це вузли Логін и create-post. Для того, щоб у текстовому полі використовувати змінну, потрібно написати ${<variable_name>}. Наприклад, url для логіну перетворюється на ${domain}/loginвідповідно для create-post вузла url буде виглядати як ${domain}/posts.

Таким чином, керуючись принципом DRY, ми трохи покращили сценарій.

Зберігаємо токен у змінну

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

Для початку виконаємо запит на логін. У вкладці Проаналізовано відповіді наведіть курсор на токен та в контекстному меню (яке викликається або правою кнопкою миші, або натисканням на кнопку …) виберіть пункт Assign to variable. З'явиться діалог із наступними полями:

• Шлях - Який шматок відповіді береться (у нашому випадку це body.token)
• Поточне значення - Яке значення лежить на шляху Path (у нашому випадку це значення токена)
• Назва змінної - Назва змінної, куди Поточне значення буде зберігатись. У нашому випадку це буде token
• вузол — у якому з предків буде створено змінну Назва змінної. Виберемо Project

Заповнений діалог виглядає так:

Тепер при кожному виконанні вузла Логін динамічна змінна token оновлюватиметься нове значення з відповіді. І ця змінна зберігатиметься в Проекти вузлі та завдяки успадкування буде доступна нащадкам.

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

Прокидаємо авторизаційний токен у запити

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

1. Вручну скопіювати токен і додати авторизаційний заголовок в запити, що цікавлять. Спосіб робітник, проте його застосування обмежується лише запитами виду «зробив та викинув». Для багаторазового виконання сценаріїв не підійде
2. Скористатися функціоналом авторизації.
3. використовувати заголовки за замовчуванням

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

Інша справа заголовки за замовчуванням! Якщо двома словами, то заголовки за замовчуванням — це успадковані від предків HTTP-заголовки, які за умовчанням додаються до запиту, якщо їх явно не відключити. За допомогою цього функціоналу можна, наприклад, продати кастомну авторизацію або просто позбутися дублювання в сценаріях. Застосуємо цю фічу для прокидання токена в заголовках.

Раніше ми передбачливо зберегли токен у динамічну змінну $dynamicVar.token на рівні Project вузла. Залишається зробити таке:

1. Визначити заголовок за замовчуванням Authorization зі значенням Bearer ${$dynamicVar.token} на рівні Project вузла. Для цього в інтерфейсі Project вузла необхідно відкрити діалог із заголовками за замовчуванням (кнопка Заголовки у правому верхньому куті) і додати відповідний заголовок. Діалог із заповненими значеннями буде виглядати так:
   
2. Вимкнути цей заголовок із login запиту. Це й зрозуміло: на момент логіну у нас ще немає токена і ми цим запитом саме встановимо його. Тому в інтерфейсі login запиту у вкладці Заголовки в області Inherited приберемо галочку з Authorization заголовка.

На цьому все. Тепер заголовок авторизації буде додаватися до всіх запитів, які є нащадками Project вузла, крім login вузла. Виходить, що на даному етапі ми вже готові сценарій і нам залишається це тільки запустити. Запустити сценарій можна, вибравши пункт прогін у контекстному меню Project вузла.

Перевіряємо коректність створення посту

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

• Надіслати запит на отримання поста за id,
• Перевірити, що ім'я сервера відповідає імені, переданому при створенні поста

Розглянемо перший крок. Якщо значення id визначається під час виконання скрипту, необхідно створити динамічну змінну (назвемо її postId) із вузла create-post на рівні Project вузла. Як це зробити ми вже знаємо, достатньо звернутися до розділу Зберігаємо токен у змінну. Залишається тільки створити запит на отримання поста за цим ID. Для цього створимо RequestStep get-post з наступними параметрами:

• Тип запиту: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

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

1. Довгий. Вручну з контекстного меню RequestStep вузла створити Assertion вузол. У створеному Assertion вузлі додати цікавий assertion і заповнити поля.
2. Швидкий. Створити Assertion вузол разом з assertion-ом із відповіді RequestStep вузла за допомогою контекстного меню

Скористаємося другим способом. Ось як це виглядатиме для нашого кейсу.

Для тих, хто не зрозумів, тут відбувається таке:

1. Зробити запит у вузлі get-post
2. У вкладці Проаналізовано відповіді викликати контекстне меню та вибрати Create assertion -> Порівняти -> Equal

Вітаю, ми створили перший тест! Просто, чи не так? Тепер можете повністю запустити сценарій і насолоджуватися результатом. Залишається зовсім трохи відрефакторити і винести title в окрему змінну. Але ми залишимо це вам як домашнє завдання)

Висновок

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

PS Для тих, кому ліньки відтворювати всі кроки, ми люб'язно запилили репозиторій із проектом із статті. Відкрити його можна за допомогою філе -> Відкритий проект та вибрати папку Project.

Джерело: habr.com