Tere kõigile. Me hakkame tasapisi välja tulema varjust ja jätkame artiklite seeriat meie tootest. Pärast eelnevas ülevaateartiklit saime palju tagasisidet (enamasti positiivset), ettepanekuid ja veateateid. Täna näitame TestMace rakendust töös ja teil on võimalus hinnata mõningaid meie rakenduse funktsioone. Kogu teabe saamiseks soovitan tutvuda meie dokumentatsiooniga aadressil http://docs-ru.testmace.com. Nii et lähme edasi!

Installeerimine

Alustame banaalsusest. Rakendus on saadaval ja seda saab testida kolmel platvormil — Linux, Windows, MacOS. Saate huvipakkuva operatsioonisüsteemi installifaili alla laadida meie veebisaidilt. Linuxi kasutajatele on olemas võimalus installida snap-pakett. Loodame, et peagi jõuame ka Microsoft Store'i ja App Store'i (aga kas see on vajalik? Mida arvate?).

Katseteema

Katses kasutame järgmist tavalist stsenaariumit:

• logime sisse: kasutaja — admin, parool — password
• lisame uue kirje
• kontrollime, kas kirje on õigesti lisatud

Testime rakendust https://testmace-quick-start.herokuapp.com/. See on tavaline json-server, suurepärane rakenduste testimiseks. Oleme just lisanud JSON-serveri kõigile teedele tokeni autentimise ja loonud login meetodi selle tokeni saamiseks. Jätkame samm-sammult, et järk-järgult täiustama oma projekti.

Projekti loomine ja proovimine luua üksus ilma autentimiseta

Alustame uue projekti loomisega (File->Uus projekt). Kui käivitate rakenduse esmakordselt, avaneb uus projekt automaatselt. Esmalt proovime teha päringu uue kirje loomiseks (juhtudel, kui kirje loomine on võimalik ilma autentimiseta). Valige kontekstimenüüs projektis punkte Lisa sõlm -> RequestStep. Sõlme nimeks paneme create-post. Tulemuseks luuakse puusse uus sõlm ja avatakse antud sõlme vahekaart. Määrame järgmised päringu parameetrid:

• Päringu tüüp: POST
• URL: https://testmace-quick-start.herokuapp.com/posts
• Päringu keha: JSON väärtusega {"title": "Uus testmace kiire alguse postitus"}
  Kui kõik on õigesti tehtud, näeb liides välja järgmine:

Siiski, kui proovime päringut teostada, naaseb server koodi 401 ja ilma autentimiseta ei ole meil sellel serveril midagi teha. Noh, see on muidugi ootuspärane).

Lisame autentimise päringu

Nagu juba mainitud, on meil POST lõpp-punkt /login, mis aktsepteerib päringu kehas järgmise kujuga json: {"username": "", "password": ""}, kus username ja password (taas, eelnevast sissejuhatusest) omavad väärtusi admin ja password vastavalt. Vastuseks tagastab see lõpp-punkt järgmise kujuga json {"token": ""}. Kasutame seda autentimiseks. Loome RequestStep sõlme nimega login, milleks vanemaks on Projekt sõlm. Asetage see sõlm lohista ja viska funktsiooni abil puu struktuuris kõrgemale kui sõlm create-post. Seadistame äsja loodud päringule järgmised parameetrid:

• Päringu tüüp: POST
• URL: https://testmace-quick-start.herokuapp.com/login
• Päringu keha: JSON väärtusega {"username": "admin", "password": "password"}

Teeme päringu ja saame vastuseks kahesaja koodi koos tokeniga. Nii see välja näeb:

Refaktoreerimine: eemaldame domeeni dubleerimise

Praegu ei ole päringud seotud ühtseks stsenaariumiks. Kuid see ei ole ainus puudus. Kui hoolikalt vaadata, võib märkida, et vähemalt domeen on dubleeritud mõlemas päringus. See ei ole hea. On aeg refaktoreerida see osa tulevases stsenaariumis ning selleks aitavad meid muutujad.

Esialgu täidavad muutujad sama rolli nagu teistes sarnastes tööriistades ja programmeerimiskeeltes — dubleerimise kõrvaldamine, loetavuse tõstmine jms. Täiendavat teavet muutujate kohta leiate meie dokumentatsioonis. Sel juhul on meil vaja kasutaja muutujaid.

Määratleme muutuja tasemel Project sõlme domain väärtusega https://testmace-quick-start.herokuapp.com. Selleks on vajalik

• Avage selle sõlme vahekaart ja klõpsake paremas ülaservas kalkulaatori ikoonil
• Klõpsake + ADD VARIABLE
• Sisestage muutuja nimi ja väärtus
  Meie puhul näeb dialoog lisatud muutuja puhul välja järgmiselt:

OK. Nüüd pärimise tõttu saame seda muutuja kasutada mis tahes tasandi alluvates. login ja create-postSelleks, et tekstiväljas kasutada muutujat, tuleb kirjutada ${}. Näiteks, sisselogimise URL muutub ${domain}/login, seega create-post sõlme URL näeb välja nagu ${domain}/posts.

Sel viisil oleme DRY põhimõtet järgides stsenaariumi veidi parandanud.

Salvestame tokeni muutuja

Kuna juba räägime muutujatest, arendame seda teemat veidi rohkem. Praegu saame eduka sisselogimise korral serverilt autentimise tokeni, mida vajame edaspidistes päringutes. Salvestame selle tokeni muutujasse. Kuna muutujate väärtus määratakse skripti käitumise ajal, kasutame selleks spetsiaalset mehhanismi — dünaamilised muutujad.

Kõigepealt teeme sisselogimise päringu. Vahekaardil Parsed kursoriga tokenile ja kontekstimenüüs (mida saab avada kas hiire parema nupuga või vajutades nuppu …) valige koht, Assign to variable. Avaneb dialoog järgmiste väljadega:

• Path — millist osa vastusest võetakse (meie puhul see on body.token)
• Praegune väärtus — milline väärtus asub teel Path (meie puhul see on tokeni väärtus)
• Variable name — muutuja nimi, kuhu Praegune väärtus salvestatakse. Meie puhul on see token
• Sõlm — millises esivanemas muutuja luuakse Variable name. Valime Project

Täidetud dialoog näeb välja järgmine:

Nüüd, iga kord, kui sõlm login dünaamiline muutuja token uuendatakse uue väärtusega vastusest. Ja see muutuja salvestatakse Projekt sõlm ja tänu pärimisele on see saadaval järglastele.

Kuidas pöörduda dünaamiliste muutujate juurde tuleb kasutada sisseehitatud muutujat $dynamicVar. Näiteks, et pääseda juurde salvestatud tokenile, tuleb kutsuda ${$dynamicVar.token}.

edastame autoriseerimise tokeni päringutesse.

Eelmistel etappidel saime autoriseerimise tokeni ja kõik, mida tuleb teha, on lisada Authorization. päisega Bearer kõigisse autoriseerimist nõudvatesse päringutesse, sealhulgas create-post. Selleks on mitu võimalust:

1. Käsitsi kopeerida token ja lisada autoriseerimise päis huvipakkuvatesse päringutesse. See meetod on toimiv, kuid selle rakendamine piirneb ainult selliste päringutega nagu „tegin ja viskasin ära”. Korduvate stsenaariumite jaoks ei sobi.
2. Kasuta funktsionaalsust autoriseerimiseks.
3. Kasutage vaikesätetes

Teise meetodi kasutamine näib iseenesestmõistetav, kuid antud artikli kontekstis ei tundu selline lähenemine... igav. Tõde on see, et autoriseerimise mehhanism on teile vähemal või rohkemal määral tuttav teistest tööriistadest (kuigi meil on sellised asjad nagu autoriseerimise pärimine) ja ei tekita äkki küsimusi.

Teised pealkirjad on muud! Ühte kokku võttes on vaikimisi pealkirjad päritud HTTP-pealkirjad, mis lisatakse päringule vaikimisi, kui neid selgesõnaliselt ei keelata. Selle funktsiooni abil saab näiteks rakendada kohandatud autentimist või lihtsalt vältida dubleerimist stsenaariumites. Rakendame seda funktsiooni tokeni edastamiseks pealkirjades.

Varem oleme ettevaatlikult salvestanud tokeni dünaamilisse muutujasse $dynamicVar.token projekti sõlme tasemel. Jääb veel teha järgmine:

1. Määrata vaikimisi pealkiri Authorization. väärtusega Bearer ${$dynamicVar.token} projekti sõlme tasemel. Selleks tuleb projekti sõlme liideses avada vaikimisi pealkirjade dialoog (nupp Headers paremas ülanurgas) ja lisada vastav pealkiri. Täidetud väärtustega dialoog näeb välja järgmine:
   
2. Käivita see pealkiri login päringust. See on arusaadav: logimise ajal ei ole meil veel tokenit ja selle päringuga me seda täpselt määrame. Seega, login päringu liideses, sakk Headers valdkonnas Inherited eemaldame Authorization pealkirja märgise.

Sellega on kõik. Nüüd lisatakse autoriseerimise pealkiri kõikidesse päringutesse, mis on Project sõlme all, välja arvatud login sõlm. See tähendab, et meil on nüüd stsenaarium valmis ja peame selle vaid käivitama. Stsenaariumi käivitamiseks valige menüüpunkt Run Project sõlme kontekstimenüüs.

Kontrollime postituse loomise õigsust

Sellel etapil oskab meie stsenaarium siseneda ja, kasutades autoriseerimisetokenit, postitust luua. Siiski peame veenduma, et äsja loodud postitus on õige nimega. Nii et põhimõtteliselt on jäänud teha järgmist:

• Saada päring postituse saamiseks id järgi,
• Kontrollida, et serverist saadud nimi vastab postituse loomisel edastatud nimele.

Vaatame esimest sammu. Kuna id väärtus määratakse skripti täitmise ajal, on vajalik luua dünaamiline muutuja (nimetame selle postId), mis asub sõlmedes create-post Project sõlme tasemel. Kuidas seda teha, teame juba, piisab, kui vaadata jaotist Salvestame tokeni muutuja. Jäänud on vaid luua päring postituse saamiseks antud id järgi. Selleks loome RequestStep get-post järgnevate parameetritega:

• Päringu tüüp: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

Teiseks sammuks peame tutvuma Kinnitus sõlmiga. Assertion sõlm on sõlm, mis võimaldab kirjutada kontrollmoodulite teatud päringutele. Igal assertion sõlmel võib olla mitu väidet (kontrolli). Lisateavet kõigi assertion-ite liikide kohta leiate meie dokumentatsioonis. Me kasutame Võrdle assertionit operaatoriga võrdne. Assertion-ite loomiseks on mitu viisi:

1. Pikk. Käskige kontekstimenüüst RequestStep sõlmes luua Assertion sõlm. Loomisel lisage soovitud assertion ja täitke väljad.
2. Kiire. Looge Assertion sõlm koos assertion-iga RequestStep sõlme vastusest kontekstimenüü abil.

Kasutame teist meetodit. Nii see meie juhul välja näeb.

Neile, kes ei saanud aru, toimub siin järgmist:

1. Tehke päring sõlmes get-post
2. Vahekaardil Parsed vastuse kontekstimenüüs ja valige Loo assertion -> Võrdle -> Võrdne

Palju õnne, me lõime esimese testi! Lihtne, eks? Nüüd saate skripti täielikult käivitada ja nautida tulemust. Jäänud on vaid veidi refaktoreerida ja viia see aadress eraldi muutujasse. Kuid jätame selle teile kodutööks)

Kokkuvõte

Selles juhendis oleme loonud täieliku stsenaariumi ja samal ajal teinud ülevaate mõnesid meie toote funktsioonidest. Loomulikult ei kasutanud me kaugeltki kogu funktsionaalsust ning järgmistes artiklites teeme TestMace'i võimaluste põhjaliku ülevaate. Jälgige uuendusi!

P.S. Neile, kellel on laisk kõike samme korrata, oleme lahkelt kallanud repo artiklis kajastatud projekti. Selle avamiseks saab kasutada File -> Ava projekt ja valida kaust Project.

Allikas: habr.com