Здравейте на всички. Постепенно излизаме от сянката и продължаваме серията статии за нашия продукт. След предишната обзорна статия получихме много отзиви (главно положителни), предложения и 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 за получаване на този токен. Ще напредваме стъпка по стъпка, постепенно усъвършенствайки нашия проект.

Създаване на проект и опит за създаване на същество без авторизация

Първо, създайте нов проект (File->New project). Ако стартирате приложението за първи път, новият проект ще се отвори автоматично. Първо, нека опитаме да направим заявка за създаване на нов запис (вдруг създаването на записи е достъпно без авторизация). Изберете в контекстното меню на узъла Project опциите Add node -> 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": "", "password": ""}, където username и password (отново, както е посочено по-горе) имат значение админ и password съответно. В отговор, този endpoint връща JSON от вида {"token": ""}. Нека го използваме за авторизация. Ще създадем RequestStep узел с име login, като предшественик ще бъде Проект узел. Чрез drag-and-drop преместете този узел в дървото над узел create-post. Задайте на новосъздадения запит следните параметри:

• Тип на заявката: POST
• url: https://testmace-quick-start.herokuapp.com/login
• Тяло на заявката: json със стойност {"username": "admin", "password": "password"}

Изпълнете запитването и получете двехиляден код с токен в отговора. Нещо такова:

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

Все още запитванията не са свързани в единен сценарий. Но това не е единственият недостатък. Ако погледнете по-внимателно, може да забележите, че поне домейнът е дублиран в и двете запитвания. Не е добре. Време е да рефакторираме тази част от бъдещия сценарий и тук ще ни помогнат променливите.

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

Определете на ниво проект узел променливата domain со значением https://testmace-quick-start.herokuapp.com. За целта е необходимо

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

OK. Сега благодарение на наследяването можем да използваме тази променлива в потомците на всяко ниво на вложеност. В нашия случай те са узелите login и create-post. За да използвате променливата в текстовото поле, трябва да напишете ${}. Например, URL за входа ще се преобразува в ${domain}/login, съответно за create-post узел URL ще изглежда така ${domain}/posts.

По този начин, следвайки принципа DRY, подобрихме сценария малко.

Запазваме токена в променлива

След като заговорихме за променливи, нека разгледаме тази тема по-задълбочено. В момента, когато успешно влезем, получаваме от сървъра авторизационен токен, който ще ни е необходим в следващите запитвания. Нека запазим този токен в променлива. Тъй като стойността на променливата ще се определя по време на изпълнение на сценария, използваме за това специален механизъм — динамични променливи.

Първо, нека направим заявка за вход. В таба Parsed на отговора задръжте курсора на токена и в контекстното меню (което се извисява с десния бутон на мишката или като натиснете бутона …) изберете опция Приписване на променлива. Ще се появи диалог с следните полета:

• Path — какъв фрагмент от отговора се взима (в нашия случай това е body.token)
• Current value — каква стойност лежи по пътя Path (в нашия случай това е стойността на токена)
• Име на променливата — името на променливата, където Current value ще се запази. В нашия случай това ще бъде token
• Узел — в кои от предците ще бъде създадена променливата Име на променливата. Ще изберем Project

Попълненият диалог изглежда така:

Сега, при всяко изпълнение на възела, login динамичната променлива token ще се актуализира с новото значение от отговора. И тази променлива ще се съхранява в Проект възела и благодарение на наследяването ще бъде достъпна за потомци.

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

Преминаваме авторизационния токен в заявките

На предишните стъпки получихме авторизационен токен и всичко, което трябва да направим, е да добавим заглавие Authorization с стойност Bearer във всички заявки, които изискват авторизация, включително и в create-post. За това има няколко начина:

1. Ръчно копиране на токена и добавяне на авторизационното заглавие в интересуващите ни заявки. Този метод работи, но е ограничен само до заявки от тип „направи и изхвърли“. Не е подходящ за многократно изпълнение на сценарии.
2. Да се възползваме от функционалността на авторизацията.
3. Да използваме по подразбиране заглавия

Използването на втория метод изглежда очевидно, но в контекста на тази статия такъв подход… не е интересен. Наистина: механизмът на авторизациите плюс-минус е познат на вас от други инструменти (макар че има и неща като наследяване на авторизациите) и едва ли ще предизвика въпроси.

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

По-рано се погрижихме да запазим токена в динамична променлива $dynamicVar.token на ниво Project възел. Остава да направим следното:

1. Определете заглавие по подразбиране Authorization со значением Bearer ${$dynamicVar.token} на ниво Project възел. За целта в интерфейса на Project възела трябва да отворим диалог с заглавията по подразбиране (бутон Headers в горния десен ъгъл) и да добавим съответното заглавие. Диалогът с попълнени стойности ще изглежда по следния начин:
   
2. Изключете това заглавие от заявката за вход. Това е разбираемо: в момента на входа нямаме токен и именно с тази заявка ще го установим. Затова в интерфейса на заявката за вход в раздела Headers в областта Inherited махаме отметката от заглавието Authorization.

На този етап всичко е готово. Сега заглавието за авторизация ще се добавя към всички заявки, които са наследници на Project възела, с изключение на възела за вход. Получава се, че на този етап вече имаме готов сценарий и остава само да го стартираме. Сценарият може да се стартира, като изберете опцията Run в контекстното меню на Project възела.

Проверка на създаването на пост

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

• Изпратете заявка за получаване на пост по id,
• Проверете дали името, получено от сървъра, съвпада с името, предадено при създаването на поста

Нека разгледаме първата стъпка. Тъй като стойността на id се определя по време на изпълнението на скрипта, е необходимо да създадем динамична променлива (нека я наречем postId) от възела create-post на ниво Project възел. Как да го направим, вече знаем, просто трябва да се обърнем към раздела Запазваме токена в променлива. Остава само да създадем заявка за получаване на пост по това id. За целта ще създадем RequestStep get-post със следните параметри:

• Тип на заявката: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

За реализирането на втората стъпка ни е необходимо да се запознаем с Assertion възела. Assertion възел – това е възел, който позволява да се пишат проверки на определени заявки. Всеки Assertion възел може да съдържа няколко твърдения (проверки). Повече за всички видове assertion можете да прочетете в нашата документацията. Ще използваме Compare с оператора equal. Има няколко начина за създаване на assertion:

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

Ще се възползваме от втория начин. Ето как ще изглежда за нашия случай.

За тези, които не разбрахте, тук се случва следното:

1. Да направим заявка в възела get-post
2. На таба Parsed отговора да извикате контекстното меню и да изберете Create assertion -> Compare -> Equal

Поздравления, създадохме първия тест! Лесно, нали? Сега можете да стартирате сценария изцяло и да се насладите на резултата. Оставя се само да рефакторите и да изнесете title в отделна променлива. Но оставяме това на вас като домашно задание)

Заключение

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

P.S. За тези, които не желаят да повтарят всички стъпки, ние любезно запазихме репозиториум с проекта от статията. Можете да го отворите чрез File -> Open project и да изберете папка Project.

Източник: habr.com