Здравейте на всички. Бавно излизаме от сянката и продължаваме серията статии за нашия продукт. След предишната прегледната статия получихме много отзиви (проводено положителни), предложения и доклади за бъгове. Днес ще покажем 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": "", "password": ""}, където username и парола (отново, от предходното въведение) имат стойности админ и парола съответно. В отговор този endpoint връща json вид {"token": ""}. Ще го използваме за авторизация. Нека създадем RequestStep възел с името login, като родител ще бъде Проект възел. С помощта на 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
• Въведете името и стойността на променливата
  В нашия случай диалогът с добавената променлива ще изглежда по следния начин:

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

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

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

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

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

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

Запълненият диалог изглежда по следния начин:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Направете заявка в възела get-post
2. В таба Parsed в отговора, извикайте контекстното меню и изберете Създайте assertion -> Compare -> Равно

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

Заключение

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

P.S. За тези, които нямат желание да преминават през всички стъпки, любезно сме записали репозиторий с проекта от статията. Можете да го отворите с помощта на Файл -> Отворете проекта и изберете папката Project.

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