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

Ўстаноўка

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

Паддоследны сцэнар

У якасці падыспытнага мы абралі наступны стандартны сцэнар:

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

Тэставаць будзем на https://testmace-quick-start.herokuapp.com/. Гэта звычайны json-server, выдатна прыдатны для тэсціравання падобных прыкладанняў. Мы толькі дадалі аўтарызацыю па токене на ўсе роуты 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, мы крыху палепшылі сцэнар.

Захоўваем токен у зменную

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

Для пачатку выканаем запыт на лагін. Ва ўкладцы Parsed адказу навядзіце курсор на токен і ў кантэкстным меню (якое выклікаецца альбо правай кнопкай мышы, альбо націскам на кнопку …) абярыце пункт Assign to variable. З'явіцца дыялог з наступнымі палямі:

Шлях - які кавалак адказу бярэцца (у нашым выпадку гэта body.token)
Бягучае значэнне - якое значэнне ляжыць па шляху Path (у нашым выпадку гэта значэнне токена)
Імя зменнай - назва зменнай, куды Бягучае значэнне будзе захоўвацца. У нашым выпадку гэта будзе token
вузел - у якім з продкаў будзе створана пераменная Імя зменнай. Выберам Project

Запоўнены дыялог выглядае наступным чынам:

Цяпер пры кожным выкананні вузла увайсці дынамічная пераменная token будзе абнаўляцца новым значэнне з адказу. І гэтая пераменная будзе захоўвацца ў Праект вузле і дзякуючы ўспадкоўванні будзе даступная нашчадкам.

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

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

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

Уручную скапіяваць токен і дадаць аўтарызацыйны загаловак у цікавыя запыты. Спосаб працоўны, аднак яго ўжыванне абмяжоўваецца толькі запытамі выгляду "зрабіў і выкінуў". Для шматразовага выканання сцэнарыяў не падыдзе
Скарыстацца функцыяналам аўтарызацыі.
выкарыстоўваць загалоўкі па змаўчанні

Выкарыстанне другога спосабу здаецца відавочным, аднак у кантэксце дадзенага артыкула такі падыход… нецікавы. Ну на самой справе: механізм аўтарызацый плюс мінус знаёмы вам з іншых інструментаў (хай у нас і маюцца штукі накшталт ўспадкоўванні аўтарызацый) і наўрад ці выкліча пытанні.

Іншая справа загалоўкі па змаўчанні! Калі ў двух словах, то загалоўкі па змаўчанні - гэта спадчынныя ад продкаў HTTP-загалоўкі, якія па змаўчанні дадаюцца да запыту, калі іх відавочна не адключыць. З дапамогай дадзенага функцыяналу можна да прыкладу, рэалізаваць кастамную аўтарызацыю ці проста пазбавіцца ад дублявання ў сцэнарах. Ужыем дадзеную фічу для пракідвання токена ў загалоўках.

Раней мы прадбачліва захавалі токен у дынамічную зменную $dynamicVar.token на ўзроўні Project вузла. Застаецца зрабіць наступнае:

Вызначыць загаловак па змаўчанні Authorization са значэннем Bearer ${$dynamicVar.token} на ўзроўні Project вузла. Для гэтага ў інтэрфейсе Project вузла неабходна адкрыць дыялог з загалоўкамі па змаўчанні (кнопка Загалоўкі у правым верхнім куце) і дадаць адпаведны загаловак. Дыялог з запоўненымі значэннямі будзе выглядаць наступным чынам:
Выключыць гэты загаловак з 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-ов:

Доўгі. Уручную з кантэкстнага меню RequestStep вузла стварыць Assertion вузел. У створаным Assertion вузле дадаць які цікавіць assertion і запоўніць палі.
Хуткі. Стварыць Assertion вузел разам з assertion-ым з адказу RequestStep вузла з дапамогай кантэкстнага меню

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

Для тых, хто не зразумеў, тут адбываецца наступнае:

Зрабіць запыт у вузле get-post
Ва ўкладцы Parsed адказу выклікаць кантэкстнае меню і абраць Create assertion -> параўнаць -> роўных

Віншую, мы стварылі першы тэст! Проста, ці не праўда? Цяпер можаце запусціць сцэнар цалкам і атрымліваць асалоду ад вынікам. Застаецца зусім крыху адрэфактарыць і вынесці title у асобную зменную. Але мы пакінем гэта вам у якасці хатняга задання)

Заключэнне

У дадзеным кіраўніцтве мы стварылі паўнавартасны сцэнар і заадно правялі агляд некаторых фіч нашага прадукта. Зразумела, мы скарысталіся далёка не ўсім функцыяналам і ў наступных артыкулах мы правядзем дэталёвы агляд магчымасцяў TestMace. Сачыце за абнаўленнямі!

PS Для тых, каму лянота прайграваць усе крокі, мы ласкава запілавалі рэпазітар з праектам з артыкула. Адкрыць яго можна з дапамогай Размовы -> Адкрыты праект і выбраць тэчку Project.

Крыніца: habr.com

TestMace. Хуткі старт